Converting code that relies heavily on DAO -- is there a "wrapper" around datatables to look like recordsets? RRS feed

  • Question

  • I have some VB6 programs I'm updating to .NET that rely heavily on "DAO" [though some is ADO-classic]; in particular, lots of code along these lines:

       dim RS as recordset
       set RS = globalDB.CreateRecordset("select * from table where condition=true", _
                                          dbopenSnapshot, dbsqlpassthrough)
       while not RS.EOF
          ' code to process a given line

    (and to make matters worse, code like that is sprinkled throughout the FORMS themselves, rather than encapsulating in classes or writing "generic" routines in modules)  As I'm looking about and learning vb.NET, I see that in the "new" standard of ADO.NET, "recordsets" are just plain GONE, replaced instead by "disconnected" tables/datasets and data "readers".  Since converting this to a proper "datatable" would mean a manual rewrite of (potentially) hundreds of such blocks of code, I wonder if anyone has written a "wrapper" around the datatable (or datareader?) to make it look like a "classic" recordset?
    Wednesday, September 19, 2007 10:52 PM

All replies

  • This would be somewhat of an ambitious endeavor given the fact that the architectures are so different. I don't think you could force ADO.NET objects to behave like DAO objects "under the covers".


    What you can do, in the meantime, is use DAO via COM interop and slowly migrate your data access code over time to ADO.NET.


    Thursday, September 20, 2007 1:16 PM
  • I suspect complete functionality would be a bit of a pain to implement, but I may be lucky in a couple of regards.  As it turns out, the application proper already uses the data returned by the recordsets in a manner similar to the "disconnected" model of .NET -- recordsets are typically read into a "spreadsheet" control [third party control, but a "grid" would suffice]; modifications are applied to the spreadsheet contents, and when the user chooses "OK", any modifications are written back to the database -- one hand-built record at a time Smile  What this means is that the majority of operations performed on recordsets are open (create), move [first/last/next], and close -- no sorting, filtering, or other obscure operations are done on them.


    As such, I've taken a pot-shot at the "wrapper" solution -- created a class that "implements DAO.recordset" (to populate all the public routines/interfaces), removed the "implements" line, then excised several routines I know are not used by the application -- at least, "it compiles" Wink   [my problem now seems to be with the dbdatareader -- I'm getting an "unable to allocate a handle" error, but I don't know if it's my code, the driver code, or because I haven't rebooted windows for a week...]


    Like I said, if anyone has already invented this wheel, please point me in the right direction...


    Thursday, September 20, 2007 4:37 PM