Question

The scenario in question relates to the much-maligned Microsoft Jet database engine. The assertion was that the Data Access Objects (DAO) data access technology is ‘native’ to Jet, the implication being that creating an object via the DAO model is ‘superior’ to doing the same via SQL code executed from within in the Microsoft Access user interface.

Furthermore, it was asserted that if you couldn’t create something via DAO then by definition it is not ‘native’ to Jet.

To me, this definition of ‘native’ seems to be misplaced. There are a number of Jet objects which, for historical and Microsoft political reasons, were omitted from or only partially implemented in DAO (CHECK constraints, fixed-width data types, the DECIMAL data type, compressible data types, etc) but were included in Jet’s SQL data definition language (DDL). Intuition alone tells me that Jet SQL DDL should be considered ‘native’ to the Jet engine.

So my question is: why would a technology seemingly external (DAO) be considered ‘native’ and another technology seemingly internal (SQL DDL) be considered ‘non-native’? Should I be troubling myself over whether something is ‘native’ or otherwise?

Answer 1

Maybe I’m wrong here, but I always understood it like this:

• the MS Jet database engine is by all means a database engine (underpowered or not)
• it’s “native” interface to the outside world is an SQL dialect

whereas:

• DAO is one of Microsoft’s database abstraction layers, designed for use in a COM environment like VBA or Windows scripting
• it was developed with Access (which can be looked at as a user interface / reporting tool for MS Jet, since MS Jet can exist without MS Access), and is strongly bundled with both MS Jet and MS Access, nevertheless it is in the same category where ADO would be in