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:
Typo fixed. Thanks. :) But does this version fix your original problem..? Previous Comments: ------------------------------------------------------------------------ [2003-08-28 03:42:01] php at jschreiber dot com I downloaded php5 directly from cvs (using the gentoo php-cvs portage), and there seems to be a typo in php5/ext/odbc/php_odbc.c, line 1433: 433c1433 < sql_c-type = SQL_C_BINARY; --- > sql_c_type = SQL_C_BINARY; ------------------------------------------------------------------------ [2003-08-28 03:16:16] [EMAIL PROTECTED] 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 ------------------------------------------------------------------------ [2003-08-27 17:53:56] [EMAIL PROTECTED] 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] [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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/25118 -- Edit this bug report at http://bugs.php.net/?id=25118&edit=1
