Bug #10469 Updated: ODBC_result() fails on DB2 LONG VARCHAR columns

ID: 10469 Updated by: kalowsky Reported By: ltning@anduin.net Status: Open Bug Type: ODBC related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: not recognizing anything as a bug yet, i haven't gotten db2 installed to try these out :P Previous Comments: --------------------------------------------------------------------------- [2001-06-08 16:14:35] ltning@anduin.net Heh.. Does that mean you recognize both as bugs, not user errors? I'd be real pleased to hear that, since I've been tearing out a considerable amount of hair over these two.. Hope you can figure it out asap, I'm currently working around the problems in various not-so-pretty ways.. -Eirik --------------------------------------------------------------------------- [2001-06-08 15:51:08] kalowsky@php.net saw the other bug too. i've seen it for awhile. it falls under the 2 problems i currently have. : --------------------------------------------------------------------------- [2001-06-02 05:02:03] ltning@anduin.net None of the two remedies you suggest make any difference. It's the odbc_longreadlen() I've been experimenting with too, but whatever I do it doesn't solve the problem, it just makes it more confusing ;) Actually.. The string in the LONG VARCHAR column might be as long or as short as you want, the same result arises anyhow. Btw, did you ever see the CHAR(x) FOR BIT DATA bug I've opened before? I was asked for feedback on it, and gave this, but nothing more happened... (It's used for the DB2 generation of unique keys...) -Eirik --------------------------------------------------------------------------- [2001-06-01 13:37:35] kalowsky@php.net depending upon the size and type of data you may need to try one of two things, or both. in your php.ini there is a line "odbc.defaultlrl" which may need to be increased. read the manual for more information on this. also you may need to call odbc_longreadlen first, again read the manual for more information on this. if either of these fixes the problem, great, if not ... as soon as I can get A) time, and B) DB2 installed on my linux box i'll check it out. --------------------------------------------------------------------------- [2001-04-24 04:32:50] ltning@anduin.net Running on IBM DB2 UDB version 7.1 for Linux, PHP compiled with --with-ibm-db2 configure option. Given the following table definition: CREATE TABLE foo (bar1 INTEGER, bar2 LONG VARCHAR) Connecting to the database: $conn=odbc_connect("TESTDB", "username", "password"); Inserting data: $rc=odbc_exec($conn, "INSERT INTO foo VALUES (1, 'This is some really long data..')"); And then running the following script: for($i=1;$i<3;$i++) { $rc=odbc_fetch_row($q, 0); $result=odbc_result($q, $i); echo "Data:".$result; } The first iteration returns the data from bar1 correctly. The second iteration will give the following error on the line containing the ODBC_result() call: Warning: SQL error: [IBM][CLI Driver] CLI0115E Invalid cursor state. SQLSTATE=24000, SQL state 24000 in SQLGetData in /home/ltning/webmail2/functions/test.php on line 10 I have found that I do NOT get this error if I do not use the ODBC_fetch_row() function prior to the second iteration (moving that line out of the loop). My theory is that the DB2 engine handles ODBC_fetch_row() & ODBC_result() calls differently when LONG VARCHAR fields are involved than otherwise, and PHP does not know how to handle this. I need to use the ODBC_fetch_row() on every iteration because I'm creating custom database functions, and there should be nothing directly "wrong" with that. I.e. this _should_ work.. If I can provide any other information, please tell me.. ;) Best regards, Eirik Overby --------------------------------------------------------------------------- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10469&edit=2