--- Lynn Fredricks <[EMAIL PROTECTED]> wrote: > > If you were to prioritize improvements to database > access in Revolution, > what would you want? > > Best regards, > > > Lynn Fredricks > Worldwide Business Operations > Runtime Revolution, Ltd >
Ooh, where shall I start? *grins as he cracks his knuckles* Don't get me wrong: one of the reasons I fell in love with Revolution, years after HyperCard lured me into programming, was the database access functions. Along with the internet stuff, zippy speed and cross-platform development on top of the elegant xCard paradigm. But it's just one of those areas where you get all excited about those one or two little extra things that would make a solid product stellar. So here comes my list: 1) Native drivers for as many databases as possible - evangelize the platform and convince the database builders to write the drivers themselves ; if they're not helpful, sit down with companies like Actual Technologies that produced ODBC drivers for Access and MS SQLServer for Mac. 2) Improve the ODBC revdb driver so that it gives us the best options where available, and uses its own temporary storage mechanism to compensate for forward-only cursors. 3) Document and expand the 'revdb_tablenames()' function so that we can get the names of tables in a database without having to construct queries that are database dependent 4) On a similar note, add a 'revdb_fieldnames()' function that returns a list of the fields in a table for a given database connection 5) Add convenience functions that return single records or entire record sets as an array or in XML format; not that important as we can script this ourselves, but C code might do it faster, especially since it's close to the data and doesn't have to communicate through the XCMD layer 6) Improve transaction support: right now you can commit and rollback transactions, but you can't tell the DBMS when the transaction starts? If possible, allow nested transactions. (You could call this 'revdb_starttransaction', and make it a function that returns a transaction ID number that we can use to commit or rollback the individual transactions; if the database doesn't support transactions, return a string with a 'revdberr' message) 7) A little more exotic now: could you make the revdb library run in its own thread, and allow callbacks, similar to the socket communication model? (That way we could just fire off a lengthy query and the app UI remains responsive; we could get the data back in portions and start filling in table fields progressively. Bonus points for the ability to cancel queries that are in progress.) Of course, I'm a tad biased, as my day job is building Finance and ERP solutions on the Progress OpenEdge platform. Items 2 through 4 should help anyone connect to databases, and Item 1 is no surprise either. Item 5 is something that we can do ourselves, while Items 6 and 7 will make it more attractive for the Enterprise market. My two eurocents, Jan Schenkel. Quartam Reports for Revolution <http://www.quartam.com> ===== "As we grow older, we grow both wiser and more foolish at the same time." (La Rochefoucauld) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution