RevDB

Yennie at aol.com Yennie at aol.com
Mon Jan 27 19: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.html>


More information about the use-livecode mailing list