Many people don’t like the idea of putting binary files in a database. I on the other hand have always enjoyed having all data, textual and binary, in the same place. What better than having it all nicely tucked away in a comfy database. The site is handled by the version handling system and the data is backed up in the normal db backup routine.  But when the system is a RedHat 7.3 using ASP mixed with PHP with ODBC connections to an MS SQL Server I really start to grind my teeth.

I didn’t want to rewrite things for free. So when I took the site onboard I only had to rewrite the actual file uploading. As it is using SUN One ASP (former Chilisoft ASP) I had to use the Chili component for this. It all went smoothly until I tried to put the uploaded data into the database. For some reason I just couldn’t get the Recordset to be updatable.

Set rs1 = Server.CreateObject("ADODB.Recordset")
sql = "select id, prodpic from product where id = '" & ref & "'"
rs1.Open sql, conn, 3, 3
rs1.Fields("bild").appendChunk picturechunk
rs1("bild").value = fblob
rs1.Update

As I don’t really like, or know, ASP (I haven’t touched VB since VB4 was new and Microsoft said it was as fast as compiled C++) I decided that the quickest way out of this would be to convert the script to PHP. As the application is a horrible mix already I figured it wouldn’t make things worse. That should do it. No problem at all.

Well it was a problem. ODBC has this limitation on the size of an SQL statement. You can only send through SQL statements with a maximum of 4096 bytes (or something like that). I knew this and I also knew you solve it by using a combination of the methods odbc_prepare and odbc_execute. You have two different ways of sending binary data this way. Well the ODBC driver (Free TDS) puked on me again and again. Go figure.

Then as the genius I am I said to myself. Chunks, concatenation. Yeah. Something like below should work. I’ve done the same with MySQL queries in some circumstances.

$fdata = base64_encode(get_file_contents($filepath));
$total = strlen($fdata);
$pos = 0;

while ($pos < $total)
  {
      $len = ($pos + 2048 > $total) ? $total - $pos : 2048;
      $substr = substr($fdata, $pos, $len);
      $sql = "update product set prodpic = prodpic + '$substr' where id='$ref'";
      db_exec($sql);
      $pos += $len;
  }

After puzzling awhile over the weird results this gave I turned to the almighty web for answers. It turns out MS SQL Server only supports concatenation of datatypes not capable of storing large amounts of data. So for the datatypes image and text it is impossible. Wonderful.

So now I just save the files on the filesystem instead. Have to setup backup routines for the machine though. Something I thought would take about an hour to fix finally took more than two days of coding and research.

Hopefully I learn some valueable lesson from all of this but I’m sure I won’t.

I never thought the day would come when I would setup a system using something as old as RedHat 7.3 when not even RedHat 9 is supported any longer. Actually, I didn’t think I would ever setup a website using both PHP, ASP, SQL Server and odbc at the same time.

Well, around came a friend of mine with weird corporate site where ASP was mingled together with PHP. Odbc is used in both languages to call two different databases, both on SQL Server. To complicate life even further PHP pages opened ASP pages via http, inserting the ASP generated content into the output of PHP. The site also relied heavily upon GIF functionality in the GD module which is no longer supported in newer versions.

As installing and running it on a windows box failed because of compatibility issues with GD my friend asked me to try getting it to work on Linux. In hindsight it would perhaps have been easier to skip the GIF functionality from start as I soon decided to not run an old GD anyway. So firstly I changed their code to use PNG instead of GIF which went very well. At this point it would probably have worked on the Windows platform but as I am sucker for *nix I never thought twice before proceeding.

Then came the problems. Chilisoft ASP or Sun Java System Active Server Pages as it is called nowadays only supported version 7.3 of RedHat linux. I tried RH 9 first but I failed to get it to work even though there are hints here and there that it is possible to make it work. (No I haven’t tried RedHat Enterprise Linux yet and I still like RedHat) So after several nights of frustration, trying in vain to get it to work, I downloaded version 7.3 and everything worked out of the box. The admin interface is very simple and the odbc connections for Sun ONE ASP were easy to setup as well. Splendid!

Sun ONE ASP administration console

Finally I had to get the odbc module working for PHP as well. I decided to go with iODBC from OpenLink Software. It was easy to build and after that I rebuilt PHP with odbc support. The problem was the drivers available. OpenLink software only had commercial drivers which to me seemed to install loads of unnecessary stuff for .NET, Mono, XML, POP3 and more.

It took me awhile to figure out that FreeTDS, that I had previously compiled and installed for SQL Server support, could be built to produce an odbc driver for iODBC. I just had to compile FreeTDS and IODBCin the right order. First the iODBC driver manager and then FreeTDS. I recompiled FreeTDS and it automatically created the odbc driver.

By this time I was quite tired and made a few mistakes with the configuration resulting in more unneeded frustration. Even so, it seems to work as well as it should. The only problem I can see now that I have it working is the lack of resources on the web describing the setup of PHP using odbc. As it is, information is scattered here and there and you have to put the bits and pieces together yourself. Is it that mostly professionals or companys use odbc and that they seldom find the time or reason to share their experiences? Anyway, in total it took me around six hours not counting the RH 7.3 installation. Tired but satisfied I could finally go home and get some sleep.