RevDB
Yennie at aol.com
Yennie at aol.com
Mon Jan 27 14:39:00 EST 2003
> <<Not necessarily true? Rev supports all systems that have an ODBC driver.
> That would include the OODBs that I mentioned.>>
>
You are correct- I overlooked the ODBC connectivity when I made that comment.
<<Sorry, maybe I misunderstood. The client-side concept of rows, that is:
rows of the query result set, I think is implemented by revdb's concept
of cursors. see the revdb_move*, revdb_cursor*, revdb_query.>>
Agreed. But even when I move with revdb_next / revdb_prev, etc... I can't
fetch even the current row- I can only grab a column.
<<Because not all database are as cool as Valentina. Some client/server
databases like Oracle or ODBC demand that you use forward only cursors.
You can't just jump back and forth between records willy nilly. But you
have a point it would be cool if you could just jump to a record by
number, for those databases that support it.>>
OK, now I see where the logic comes from- and that makes sense. But Oracle
and ODBC certainly do allow you to move forward and to fetch the current row.
I know it *can* be done with the current API, just consider this script that
I wrote for use with MySQL:
## fetch rows 100-150 of the results of a query
function fetchRows dbRef, theSQL, startRecord, endRecord
local tResult
put revdb_query(dbRef, theSQL) into theCursor
repeat (startRecord - 1)
revdb_movenext(theCursor)
end repeat
repeat (endRecord - startRecord + 1)
repeat with i=1 to revdb_columncount(theCursor)
put revdb_columnbynumber(theCursor, i) into theValue
put theValue&tab after tResult
end repeat
put cr into last char of tResult
revdb_movenext(theCursor)
end repeat
revdb_closecursor(theCursor)
delete last char of tResult
return tResult
end fetchRows
This kind of function works. It's just that I typically have to make as many
as 500+ calls to revdb to fetch 50 records. MetaTalk is fast- but is this
*really* necessary?
I'm not sure why we are discussing the various implementations of rows in
Oracle, ODBC, etc.
Not all database implementations necessarily have "rows"? Then why is there a
revdb_querylist() function whose entire purpose is to fetch *all* of the
rows? This just seems like technical misdirection here- this is about
useability, not database implementations. There *could* be a
revdb_currentrow() function, there just isn't. I just think it's worth
implementing- I for one moved to a professional Rev license for one reason,
and that is database support. RevDB is AWESOME. But I doubt this will be last
time a database developer scratches his head when he can't fetch even the
current row from a database cursor.
I can script around it- if others don't need this, then I guess I'm on my
own.
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.runrev.com/pipermail/use-livecode/attachments/20030127/439fddbd/attachment-0023.htm>
More information about the use-livecode
mailing list