Some of these tricks go back to VBClassic, but most all of them apply to ADO.Net development too.

I recall writing a GuestOp for VBPJ back in the 90's and having a reader comment that Jet development is only for noobs and real devs use Oracle or SQLServer exclusively.  Well, having worked Oracle and SQLServer gigs for years I can tell you that Jet still has major benefits... usually not as an "Access" solution but as a killer bit of middleware.

Consider this realworld use:

At drugstore.com, a pretty hefty company, there was an immediate need to provide specialized reports to insurance carriers on exact timings of each step of all prescriptions going through the systems from front end orders to back end human and automated workflows to billing and shipping.  Multiple Oracle databases - transactional and data warehouse - held the data and cross joins were simply not possible.

The solution was to dynamically create a Jet file, dynamically adding multiple raw tables, hit the various Oracle marts & instances to INSERT into the Jet tables then run JetSQL joins and calculations into result tables. 

What's more the insurance companies believe that Excel is a data format so using Export to Anything techniques we could dump the results with full complex formatting into Excel worksheets.

When the Excel files were done the app simply deleted the Jet files. 

Jet as middleware, Jet files as temp files.

A major solution for a major business need and a major save of the pain of using "real database" temp tables and some 3rd party tool to export to Excel then human time for formatting.

All that a pro dev needs to do this kind of work is knowing the tricks of Jet presented here... and an open mind about getting things done instead of being an elitist ;-)

By the way, when you see pre-.Net code examples here, remember: the system I just described was all done by coming back to these pages for the basic ADO code and then just using it with ADO.Net and C# syntax (and VB.Net code spit out by the DBCreator because there was no need to port it even when a non.Net manager showed his .Net ignorance by saying "no VB".  .Net is .Net, it's the framework not the syntax).  And when it comes to power herein, it's about the Jet engine, not the language Or the dev platform.

Just gotta poke around.

smith