ID: 6294
Updated by: kalowsky
Status: Open
Bug Type: ODBC related
Assigned To: 

Please use the Bug system to respond to bugs.

User Reports:

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:

[2001-04-09 11:11:12] [EMAIL PROTECTED]
Judging by your second comment, would you consider this bug closed?


[2000-08-22 11:26:07] [EMAIL PROTECTED]
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.



[2000-08-22 09:34:14] [EMAIL PROTECTED]

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


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at

PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to