php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #25118 ODBC: can't store data in blob fields
Submitted: 2003-08-17 13:17 UTC Modified: 2017-01-08 06:22 UTC
Votes:9
Avg. Score:4.4 ± 0.8
Reproduced:5 of 6 (83.3%)
Same Version:3 (60.0%)
Same OS:0 (0.0%)
From: php at jschreiber dot com Assigned: krakjoe (profile)
Status: Closed Package: ODBC related
PHP Version: 4.3.4 OS: GNU/Linux (Gentoo)
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2003-08-17 13:17 UTC] 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''".

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-08-28 05:02 UTC] php at jschreiber dot com 
Sorry, guys...! It still doesn't work. I tried it with my "blobtest" 
(http://www.jschreiber.com/php/blobtest/). the insert statement 
gets executed, but the blob only contains an empty value (x''). 
I uploaded a new db2 trace to 
http://www.jschreiber.com/php/blobtest/db2trace_new.txt 
 
I hope that helps you!! Again, thank you for trying to fix that. Jan
 [2003-09-08 19:09 UTC] php at jschreiber dot com 
I looked at my last trace one more time and saw that 
 
SQLBindParameter( hStmt=1:1, iPar=1, 
fParamType=SQL_PARAM_INPUT, fCType=SQL_C_CHAR, 
fSQLType=SQL_BLOB, cbColDef=1048576, ibScale=0, 
rgbValue=&0000000a, cbValueM 
ax=0, pcbValue=&0820563c ) 
    ---> Time elapsed - +6.810000E-004 seconds 
 
is being called with fCType=SQL_C_CHAR instead of 
SQL_BINARY. So I applied a part of Clara Lius patch to the 
code and changed the line containg SQL_LEN_DATA_AT_EXEC as 
described in my last comment. Now my "blobtest" script 
runs fine!! 
 
But the problem seems not to be totally solved - the 
odbc-test that comes with php seems to "hang" on some 
statements--sometimes it works, sometimes not...  
 
Anyway, I think that was a step in the right direction, so 
here is my patch: 
http://www.jschreiber.com/php/blobtest/blob-patch.txt 
 
Jan
 [2003-10-22 19:46 UTC] kalowsky@php.net 
Marking this as a verified bug, in the sense that I know it exists.  BLOB support in the ODBC system as it stands is relativly, umm, not useful.  I haven't a good solution to this right now though.
 [2004-02-25 12:55 UTC] jerome dot dury at cegedim dot fr 
Hello,
I don't think this is really not useful, because we're trying to build a php script to insert blobs in a DB2 database. Our solution was pretty robust : it was to re-use some php objects and their relative methods that we implement in our php web site, in our back-office procedures...
Because of this bug we are forced to rewrite our procedures with perl-dbi or visual basic, which provides blobs insertions.
Are you planning to fix this bug ? Or do you leave it like this ?

Thanks

J?rome
 [2004-03-06 14:00 UTC] php at jschreiber dot com 
I think I've finally fixed this bug. Here is my patch:

http://www.jschreiber.com/php/blobtest/patch.txt

The patch worked with PHP 4.3.x and IBM DB/2 8.1 Fixpack 3 and 4. It has been tested using Linux and Solaris.

Apply this patch with

cd /path/to/source/php-4.3.4/ext/odbc
patch -p1 < /path/to/patch/patch.txt

Hope this helps somebody!
Regards, Jan
 [2004-03-09 12:08 UTC] kalowsky@php.net 
Unfortunately the type SQL_BLOB only exists on DB2 and 
as such makes this patch pretty useless for the rest of 
the ODBC users.
 [2004-03-09 18:16 UTC] php at jschreiber dot com 
Uhm, originally I wanted to give DB2 users the chance to evaluate this patch first. But if you think that wrapping the modified lines with 

#if defined(HAVE_IBMDB2)
#endif

directives will be enough to save poor non-DB2 users from the evil SOL_BLOB, you can take a look at the updated version of the patch at 

http://www.jschreiber.com/php/blobtest/patch.txt

Jan
 [2010-12-22 15:17 UTC] johannes@php.net
-Package: Feature/Change Request +Package: ODBC related
 [2017-01-08 06:22 UTC] krakjoe@php.net
-Status: Verified +Status: Closed -Assigned To: +Assigned To: krakjoe
 [2017-01-08 06:22 UTC] krakjoe@php.net 
This would appear to be yet another issue with the ODBC driver.

There are better drivers for ODBC today, and it would seem that everybody is using those, because these bugs are not generating any interest/conversation and haven't for a decade.

If anyone thinks I'm wrong to close this, please open a PR to improve ODBC.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 09:01:27 2024 UTC