ID: 10469
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
