Re: PHP 4.0 Bug #6294 Updated: Strange behaviour when using DB2

Hi, >Judging by your second comment, would you consider this bug closed? No, since the GENERATE_UNIQUE() function, which relies on a FOR BIT DATA field still won't work. It seems to be the FOR BIT DATA variants of the CHAR fields that PHP has problems with, and even though I haven't bumped into more situations where I need this, It sure will happen at some point - I can imagine I'll encounter the problem when we next month start to store product pictures in the database. A such field type would be convenient to use, as an alternative to xLOB fields.. Best regards, Eirik Overby >Previous Comments: >--------------------------------------------------------------------------- > >[2000-08-22 11:26:07] ltning@anduin.net >I have been able to narrow the problem down to the useage of the "FOR BIT DATA" >modifier to the CHAR type. > >To use the GENERATE_UNIQUE() function in DB2, one must have a CHAR(13) FOR BIT DATA field. When >working with a table with such a field, PHP seems to choke and do many strange things.. Now that I >redesigned the database into just using plain CHAR(13) fields (planning to use uniqid()), everything >seems to work a lot better. > > >-Eirik > >--------------------------------------------------------------------------- > >[2000-08-22 09:34:14] ltning@anduin.net >Hi! > >Having installed DB2 and compiled PHP with --with-ibm-db2 option, set the environment properly >and started apache/php, I have the following situation: > >Connecting to the database works fine. >Inserting data into tables in a database works fine, it seems. I can view the data using the >command line interface to DB2 or any other tool. > >Selecting from a table, however, is rather flakey, at best. > >In my case, doing a "SELECT * FROM bar" seems to work, but when using >odbc_result_all() to print the result set, the first field (an ID field, CHAR(13) BIT DATA) shows as >either empty or with strange data. This strange data is, in this case, either "ml>" >(part of "<html>"??) or "/usr/bin:/usr/sbin:/usr/local/bin:"........ .. >Seems to be a environment variable on my system. >When running it through PHP4 for OS/2 instead, these "strange data" are either >"ml>" or parts of the SQL statement. > >Doing a "SELECT foo FROM bar" returns nothing at all, even though the exact same >statement returns the data I want in any other tool I use to manage the database. > > >This sounds to me like a nasty bug - pointer problems or something? - in your code.. Either >that, or it's something stupid I've done. ;) > >Hope this can be resolved as soon as possible, since we're about to do a company-wide >transition from MySQL to DB2 these days. This encounter is a serious set-back .. > > >Best regards, >Eirik Overby >Freepoint Networks GmbH >Haburg, >Germany > >--------------------------------------------------------------------------- > > > >ATTENTION! Do NOT reply to this email! >To reply, use the web interface found at >http://bugs.php.net/?id=6294&edit=2 > >