ID: 25118 Updated by: [EMAIL PROTECTED] Reported By: php at jschreiber dot com -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: GNU/Linux (Gentoo) PHP Version: 4.3.2 New Comment:
Try a snapshot of PHP 5 Previous Comments: ------------------------------------------------------------------------ [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] [EMAIL PROTECTED] 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
