Then again, perhaps PHP's odbc_fetch_row() gets one row at a time from the DB server, instead of getting the row from a record set that odbc_exec() already pulled out (which is what I believe). I guess the real question is, what happens "under the hood" when the odbc_exec() funtion is executed.

Exactly. I assumed that odbc_exec opens the cursor, and odbc_fetch_row, well, does exactly that, fetches the row from it. Then again, it could be as you say, that odbc_exec fetches the whole result set into some internal buffer, and odbc_fetch_row just transfers a row into your variables. Well, I will be very disappointed it the later is the case.

You could try and experiment with exclusive locks (or dig through documentation and/or source) to see which is true.

I will try and poke around docs available on the web if I remember tomorrow morning (it is 2:20 AM here).

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

P.S.
I took a brief look at PHP/ODBC docs and it looks as if I might be right, but it is not 100% clear. They say that exec is combination of prepare and execute, and those are normal names for the steps in preparing and opening a cursor using dynamic SQL. It could still be that exec and execute return the whole result set somewhere, and fetch gets rows from there, but I would be surprised.

Try an experiment: take a large table and do unsorted select on it without where part. If exec returns more or less immediatelly, I am right.

Edited by bonzi on 24/10/01 01:36 AM.