Every application that I build means to reflect the three-tier abstract model within Microsoft's software design guidelines. One of those tiers is Data Services. With Access 2000 and ADO in mind, I have distilled the core data services of a DAO (native ISAM) Access application.

Here are the current tools:

One Private, module-level, Recordset Object Variable

All of the procedure designs that take advantage of Recordset objects see this variable. Frequently in my designs, the procedure needs to loop through a set of records or add records to a table---here I find such a variable useful.

One Function, Returning a Recordset Object

This function serves the Module-level Object Variable. Currently it passes arguments for only one Parameter (for parameterized queries). It needs to distinguish between tables and compiled queries.

One Function That Executes Action Queries

This function returns a value of type Long, indicating the number of records affected by the Action Query. This function replaces the "seductive" functionality of the DoCmd.RunSQL() method of the Application object.

One Function, Returning a Single Value from a Database Object

This function replaces the Dlookup() method of the Application object. It takes a SQL WHERE clause among its arguments and returns a Variant.

One Function, Returning String from tblStrings

All of my Visual Basic applications store their String Literals in a DAO table called tblStrings. I built a "special" function that is optimized to read from this table. This function features the Seek method of the DAO.Recordset object.