Bug #6294 Updated: Strange behaviour when using DB2
| From: | sander@php.net | Date: | Tue, 27 Nov 2001 10:34:55 +0000 |
| Subject: | Bug #6294 Updated: Strange behaviour when using DB2 | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-71766@lists.php.net to get a copy of this message | ||
ID: 6294
Updated by: sander
Reported By: ltning@anduin.net
Old Status: Open
Status: Feedback
Bug Type: ODBC related
Operating System: RedHat Linux 6.2
PHP Version: 4.0.1pl2
New Comment:
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?
Previous Comments:
------------------------------------------------------------------------
[2001-04-10 13:30:32] ltning@anduin.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-04-10 09:28:41] 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-09 11:11:12] kalowsky@php.net
Judging by your second comment, would you consider this bug closed?
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
Edit this bug report at http://bugs.php.net/?id=6294&edit=1