>I think this is a feature of some databases/interfaces, rather than a bug in >revdb (but will stand ready to be corrected). Some data providers will >allow you to get the number of records in a cursor, and will allow full >movement around the recordset; others will only allow you to move next, and >test whether at end. Correct. If you look at the database manager scripts you'll notice that it loops and checks revdb_iseof as a condition for ending the loop. This is the suggested method. To support this feature unfortunately for some databases, it would require having to loop through the resultset, which would be a huge waste of memory/processing time, see below.
> As far as I know, the RevDB interface does not >(currently) allow you to specify cursor type - so this may be a related >cause, and may be an area for possible improvement. But I'm not very sure >of my facts at this point.... For now it's always forward only. MySQL is the only in the current RevDB which supports moveprev, movefirst, movelast. Other databases added to RevDB in the near future may support these as well..but unless you know your app is going to be using xyz database it is best to design to use movenext only. And btw, also good to call revdb_commit after many inserts, or execute statements. MySQL saves changes to database automatically (and indeed in some databases revdb_commit does nothing), but Oracle doesn't and you need to commit(ie. flush and save the changes to the server) to keep cursors results in sync. A workaround would be to just write a routine which loops over the records and populates an array which the record/row data..and then you can move back and forth through the data unfetered (and the issue of data integrity (remember in most databases multiple users can be accessing the database at the same time) disappears. RevDB may even support an additional command in the near future which can load the data at one into an array or into a tab, delimited list , which would remove the need to have to open, fetch, then close cursors. Tuviah _______________________________________________ improve-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/improve-revolution
