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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ltning at anduin dot net
New email:
PHP Version: OS:

 

 [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: Wed May 07 22:01:27 2025 UTC