php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #6294 Strange behaviour when using DB2
Submitted: 2000-08-22 09:34 UTC Modified: 2001-12-18 07:14 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: ltning at anduin dot net Assigned:
Status: Closed Package: ODBC related
PHP Version: 4.0.1pl2 OS: RedHat Linux 6.2
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
22 + 23 = ?
Subscribe to this entry?

 
 [2000-08-22 09:34 UTC] ltning at anduin dot 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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-08-22 11:26 UTC] ltning at anduin dot 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
 [2001-04-09 11:11 UTC] kalowsky@php.net 
Judging by your second comment, would you consider this bug closed?
 [2001-04-10 09:28 UTC] kalowsky@php.net 
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
 [2001-04-10 13:30 UTC] ltning at anduin dot net 
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..
 [2001-11-27 05:34 UTC] sander@php.net 
Does this problem still occur with 4.0.6, the latest RC (http://download.php.net/~zeev/php-4.1.0RC3.tar.gz) or the latest CVS?
 [2001-12-18 07:14 UTC] sander@php.net 
No feedback. Closing.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Thu Oct 30 23:00:01 2025 UTC