<HTML><FONT FACE=arial,helvetica><BLOCKQUOTE CITE STYLE="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px" TYPE="CITE"><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2"><<Not necessarily true? Rev supports all systems that have an ODBC driver.</FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2"><BR>
</FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2">That would include the OODBs that I mentioned.>></FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2"><BR>
</BLOCKQUOTE></FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2"><BR>
You are correct- I overlooked the ODBC connectivity when I made that comment.<BR>
<BR>
<<</FONT><FONT COLOR="#000000" FACE="Arial" FAMILY="SANSSERIF" SIZE="2">Sorry, maybe I misunderstood. The client-side concept of rows, that is:<BR>
rows of the query result set, I think is implemented by revdb's concept<BR>
of cursors. see the revdb_move*, revdb_cursor*, revdb_query.>><BR>
<BR>
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.<BR>
<BR>
<<Because not all database are as cool as Valentina. Some client/server<BR>
databases like Oracle or ODBC demand that you use forward only cursors.<BR>
You can't just jump back and forth between records willy nilly. But you<BR>
have a point it would be cool if you could just jump to a record by<BR>
number, for those databases that support it.>><BR>
<BR>
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:<BR>
<BR>
## fetch rows 100-150 of the results of a query<BR>
function fetchRows dbRef, theSQL, startRecord, endRecord<BR>
     local tResult<BR>
     put revdb_query(dbRef, theSQL) into theCursor<BR>
     repeat (startRecord - 1)<BR>
         revdb_movenext(theCursor)<BR>
     end repeat<BR>
     repeat (endRecord - startRecord + 1)<BR>
         repeat with i=1 to revdb_columncount(theCursor)<BR>
               put revdb_columnbynumber(theCursor, i) into theValue<BR>
               put theValue&tab after tResult<BR>
         end repeat<BR>
         put cr into last char of tResult<BR>
         revdb_movenext(theCursor)<BR>
     end repeat<BR>
      revdb_closecursor(theCursor)<BR>
      delete last char of tResult<BR>
      return tResult<BR>
end fetchRows<BR>
<BR>
<BR>
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?<BR>
<BR>
I'm not sure why we are discussing the various implementations of rows in Oracle, ODBC, etc.<BR>
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.<BR>
<BR>
I can script around it- if others don't need this, then I guess I'm on my own.<BR>
<BR>
Brian</FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2"><BR>
</FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2"><BR>
<BR>
</FONT><FONT COLOR="#000000" FACE="Geneva" FAMILY="SANSSERIF" SIZE="2"></FONT></HTML>