RevDB

[Yennie at aol.com]

OK, I see where you are coming from. I agree that scripted solutions can be 
better than adding a lot of different functions to the API. I hadn't 
considered the usefullness of column functions for binary data. That is true.

For the record, the only reason I am so concerned about not scripting this is 
because my product is web-based, and performance is a big deal. For a lot of 
apps, I'd have no problem scripting the solution.

If you really will add the currentrow() functionality, may I suggest that 
there be a parameter for how many rows to fetch? It just makes for nicer code 
to write something like:

put revdb_fetchrows(theCursor, tab, 50) into theRows

than

repeat 50
    put revdb_currentrow(theCursor, tab)&cr after theRows
    revdb_movenext(theCursor)
end repeat

At this point I'm just making suggestions for smaller scripts... those two 
probably aren't far apart in terms of performance.

It would also be useful to allow an optional parameter to revdb_movenext(), 
so that one could hop, say, 50 rows.

Just trying to eliminate the repeat loops from my code now, it's great for 
the psyche =).

Of course if you decide against it, I can benchmark some of the scripted 
solutions and see how they stack up.

Brian

<<
> OK sure I can add revdb_currentrow. It's just as an external/engine
> developer the first question you have to ask yourself is -can it be
> scripted?- The cool thing about revdb_columnbynumber is that it can also
> be used to access binary data..which is the sort of thing you want to
> access column by column. In addition returning data as tab or comma
> delimited requires that you parse the data anyhow to access each
> individual column.
> 
> Even revdb_querylist is a conveniance, and something that can probably be
> implemented at the script library level.>>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.runrev.com/pipermail/use-livecode/attachments/20030127/642b2788/attachment.html>