I've been having some trouble with the Openlink ODBC drivers & PHP.  I've
been working with Openlink to resolve the problems for quite some time, and
I finally got them to look at it in detail.  Unfortunately, they're pointing
the finger back at PHP, and I don't understand this stuff in enough detail
to know if there  is anything that can be done within PHP to fix it.

In a nutshell, there are 2 issues.  The first issue is that when I use
odbc_num_rows, it works fine for a directly executed statement, but fails
when using prepared statements.

#2 is similar - when I use odbc_fetch_row and I specify the row number that
I want to fetch, it works fine for a directly executed statement, but fails
when using prepared statements.

I ran some tests, and forwarded all of the debug messages to Openlink, and
here's what I got back from them:

>I believe what's happening here is that you / PHP have not set any
concurrency
>nor a rowset size prior to calling SQLExtendedFetch(). This is possibly due
to
>the fact that PHP is requesting a dynamic cursor, whereas we implement a
KSD
>cursor (keyset-driven) instead - note the SQL_SUCCESS_WITH_INFO return
state of
>SQLSetStmtOption(6,2), which is the call to go into dynamic mode. If PHP is
>ignoring this return state, it could be assuming that it doesn't need to
set
>concurrency or rowset sizes.

>Is there anything you can do in PHP to fix this?

BTW, my preference is to directly execute statements rather than use
prepared statements, however Openlink has some unresolved issues with the
way escaped quotes are handled with directly executed statements, so I
basically have no choice.

Environment is AIX 4.2.1, Openlink is the latest version from their website.  I've also compiled in MySQL support.  PHP is version 3.0.5 running as an Apache module (1.3.0).  Database is Progress version 7.3E. 

Thanks in advance for your help.