ID: 25118
Updated by: sniper@php.net
Reported By: php at jschreiber dot com
Status: Feedback
Bug Type: ODBC related
Operating System: GNU/Linux (Gentoo)
PHP Version: 4.3.2
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
------------------------------------------------------------------------
[2003-08-27 17:53:56] kalowsky@php.net
Try a snapshot of PHP 5
------------------------------------------------------------------------
[2003-08-20 15:42:29] php at jschreiber dot com
DB/2 V8.1.2 works fine with (afaik) other language bindings (e.g.
C, C++) but not with PHP. We run a relatively large DB2
installation at the university and all other applications work fine
with the new version--except the PHP ones. This means for me,
that this is a PHP problem.
I talked to some PHP guys at the LinuxTag in Karlsruhe and they
told me that I should post a bug report here, because some
vendor specific stuff (something at ODBC level - I can't
remember) changes from time to time and they told me that the
driver on the PHP side has to be modified to work together with
newer database releases. That's why I posted here.
I didn't want to provide my initial test code for reasons of
simplicity and since I could reproduce the bug with the odbc-test
included with php. But here we go:
http://www.jschreiber.com/php/blobtest/
contains all files I used for testing.
- db2cli.ini contains the settings that I got from the article
mentioned above (only the [wwwasa] and the [common] section
are relevant--the rest is ibm sample data).
the longdatacompat option is only relevant for retrieving blobs (I
never came so far, since i couldn't store them)
- test.txt was the file I tried to upload (could be a binary image file
as well)
- db2trace.txt was a trace that I produced using the trace function
(TRACEFLUSH=1, TRACE=1 in db2cli.ini). This could be
interesting for you (and further debugging).
- db2test.phps contains the test program.
But, as mentioned above, I could reproduce the error with the
odbc-test as well. Since I didn't activate tracing and since the
LONGVARCOMPAT option is only for downloading, I didn't
modify anyting in the odbc-test sources.
Does maybe the trace help you? The weird thing is, that the trace
doesn't include any error or warning messages, but the result
was still an empty entry in the blob field (x'').
I hope that helps, and thank you for trying to solve this problem!
Jan
------------------------------------------------------------------------
[2003-08-20 13:23:49] kalowsky@php.net
I don't see how this is a PHP problem if the problem arose when you
upgraded databases. If you have tried what was in that article, why
not share the altered code, as that would help debug what has gone
wrong.
------------------------------------------------------------------------
[2003-08-17 13:17:30] php at jschreiber dot com
Description:
------------
I have a problem concerning BLOB fields and DB/2 V8.1.2.
When I try to store a file with odbc_prepare() and
odbc_execute($stmt, $params) no error code is returned, but the
BLOB contains an empty value ("x''", not a NULL value).
I had this bug since I upgraded from DB/2 7.1 to DB/2 8.1 (and
DB/2 8.1.2 as well).
It's not a programming error--all script were working with DB/2
7.1. It even occurs with the odbc-test included in tests/ directory
of the php source distribution.
I tried all tricks mentioned at
http://www7b.software.ibm.com/dmdd/library/techarticle/0301liu/0301liu.html
but without success.
Reproduce code:
---------------
odbc-t5.php from the tests/ directory of the php source distribution.
Expected result:
----------------
Actual result:
--------------
This is the output:
--- snip ---
ODBC Test 5 - Blobs
Connecting to test as db2inst1 - OK
Dropping table "php_test" - OK
Creating table "php_test": - OK
Table Info:
Name Type Length
ID CHAR 32
GIF BLOB 100000
Inserting data: /tmp/phpnyprAM - - - OK
--- snap ---
It looks like everythings works fine, but the the database contains
just "image1" and "x''".
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=25118&edit=1