This project has moved and is read-only. For the latest updates, please go here.

Implementing subset of DAO360.Recordset object on top of esent

Nov 19, 2010 at 1:02 PM


I am currently in the process of building an object that will implement a very small subset of the functionality found in the Recordset object from DAO3.60 (Jet "Red"/ms access). The object will primarly be used as a table-type recordset, thus leaving out any support for relations/queries/tabledefs.
The reason for creating this object is to enable an upgrade path for our very old codebase to a new combination of iis7.5/, and to be able to use this recordset object as a drop-in replacement for the dao 3.6 recordset object.

The "esent recordset" object currently supports the following methods also found in a DAO360.Recordset object:

  • Cursor move operations (movefirst/movelast, movenext/moveprevious)
  • Seek
  • Cancel
  • Close


  • EOF, BOF, NoMatch, Index


  • Fields

There is also a few internal helper methods to map between ESENT data types and DAO data types, and the schema metadata is cached during application start.


I have a few questions about implementing the Recordset.Fields collection.
In DAO 3.6 the Recordset.Fields is a collection of each column (DAO.Field) in the current table, and its Value property is used to get/set column data. DAO.Field.Value is of type Variant.

I populate all value properties for each DAO.Field the first time a field value is requested, but I have also attempted to do lazy loading (e.g don't load a field value until is requested).
This means looping through each field, looking at the DAO data type, then mapping that to the corresponding Esent data type, and calling the proper Esent Retrievedata helper method.
As far as I can see there is performed a lot of heavy lifting/marshalling in the esent retrievedata helpers - are there any optimization gotchas I should be aware of when doing it this way?

When it comes to updating field values back to esent, I am tracking the dirty state of each field and will update all dirtied fields with a single call to JetSetColumns.


Performance-wise I am trying to keep track of the added overhead from my recordset object by doing WCAT load testing on code that uses managedesent directly versus my object (looking at http requests/second and cpu load). I've also looked into the C++ CRecordset implementation, especially the record field exchange parts (


Good suggestions and insight to this crazy idea are more than welcome.. :)