Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / DB2 Topics / November 2005

Tip: Looking for answers? Try searching our database.

CLI0005W from query with join in PHP script

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Larry Menard - 23 Nov 2005 20:56 GMT
  Folks,

  I have a PHP script that does:

 $statement = 'SELECT tbl1.col1, tbl2.col2 FROM tbl1, tbl2';
 $result = odbc_prepare($dbconn, $statement);

  It succeeds, but always generates warning:

 PHP Warning:  odbc_prepare(): SQL error: [IBM][CLI Driver] CLI0005W  Option value changed. SQLSTATE=01S02, SQL state 01S02 in SQLPrepare in C:\temp\cli0005w.php on line 28

 Warning: odbc_prepare(): SQL error: [IBM][CLI Driver] CLI0005W  Option value changed. SQLSTATE=01S02, SQL state 01S02 in SQLPrepare in C:\temp\cli0005w.php on line 28

  I think I understand what the error means.  When I use the Microsoft ODBC driver it says:

 Warning: odbc_result() [function.odbc-result]: SQL error: [Microsoft][ODBC Cursor Library] Positioned request cannot be performed because result set was generated by a join condition, SQL state SL002 in SQLGetData in C:\My Server\gallery2\test-non-adodb.php on line 83

  So I presume the CLI0005W means CLI is invoking some extra hoops in order to execute the statement, for which I am grateful, but I don't want PHP to report it.

  I've tried modifying the error_reporting() in the PHP script, but can't seem to get rid of the warning.

  Is there any way to suppress (or prevent) these warnings at either level, DB2 or PHP?

  Thanks.

Signature

--------------------
Larry Menard
"Defender of Geese and of All Things Natural"

Knut Stolze - 24 Nov 2005 08:13 GMT
>    Folks,
>
[quoted text clipped - 30 lines]
>    Is there any way to suppress (or prevent) these warnings at either
>    level, DB2 or PHP?

If you don't add an explicit FOR READ ONLY at the end of the query, PHP
automatically adds a FOR UPDATE.  So it tries to give you an updatable
cursor on a joined table, and that cannot work.  Add the FOR READ ONLY and
you should by fine.  I found that adding this clause wherever possible is a
good idea when PHP is involved.

Oh, and if you use PHP with BLOBs, you might hit quite a few problems...

Signature

Knut Stolze
DB2 Information Integration Development
IBM Germany

Dan Scott - 24 Nov 2005 13:17 GMT
The Unified ODBC extension for PHP uses scrollable cursors for every
query in DB2. Worse, it uses a kind of scrollable cursor that DB2
doesn't support, so the client and server go back and forth negotiating
a supported scrollable cursor level _for every row you request_. Which
means that retrieving data from a remote server is crazy slow.

All of this, along with workarounds for the problem, is well-documented
here:
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0502scott/index.html

I see you're using ADODB; we really need to get the ibm_db2 extension
for PHP (http://php.net/ibm_db2) supported in ADODB, because until
that's available anybody using ADODB to connect to DB2 through Unified
ODBC is going to think that the database is the bottleneck. The ibm_db2
extension does things right (including BLOB support, defaulting to
forward-only cursors but enabling you to use scrollable cursors on a
statement by statement basis, and support for OUT/INOUT parameters in
stored procedures).

Dan
Larry Menard - 24 Nov 2005 14:30 GMT
  Thanks, Knut & Dan.

  That was the problem, thanks.  I had forgotten that particular nastiness,
and didn't realize this was a case of it.

  My simple test described below was not using ADOdb, but Dan knows that
the original application (from which I rendered the testcase) is.  On one
hand I await support for ibm-db2 in ADOdb anxiously, but on the other hand I
know that no change is ever without its new problems.  ;-)

Signature

--------------------
Larry Menard
"Defender of Geese and of All Things Natural"

> The Unified ODBC extension for PHP uses scrollable cursors for every
> query in DB2. Worse, it uses a kind of scrollable cursor that DB2
[quoted text clipped - 16 lines]
>
> Dan
Larry Menard - 24 Nov 2005 15:44 GMT
  Turns out I'm still getting the CLI0005W from a lot of queries.  One
example is a query that does a select from a LONG VARCHAR column.

  Is this the same problem Knut mentioned regarding BLOBs?  In Clara Liu's
article she mentions LOBs getting CLI0005W, but her solution is to use FOR
READ ONLY.  I'm now using that clause, and it isn't helping.

  Any other suggestions?

  Thanks.
Signature

--------------------
Larry Menard
"Defender of Geese and of All Things Natural"

> The Unified ODBC extension for PHP uses scrollable cursors for every
> query in DB2. Worse, it uses a kind of scrollable cursor that DB2
[quoted text clipped - 16 lines]
>
> Dan
Dan Scott - 25 Nov 2005 15:50 GMT
Larry:

Retrieval of LOBs and (I believe) LONG VARCHARs in scrollable cursors
is not supported by DB2, ergo warnings or errors are to be expected
with Unified ODBC. :(

Dan
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.