[AccessD] Access Queries

Arthur Fuller fuller.artful at gmail.com
Mon Feb 20 12:13:52 CST 2012


I was unaware that Access 2010 had the bug described, so if and when I go
there I may have to change my approach, but I almost never build up SQL
strings in code, and in fact when working on an inherited app that's
usually one of the first things I target for change. I find that code and
build a query from it using the designer. For more complex queries, I
usually break them down into several queries (which I call atomic queries),
then combine the queries into a molecular query. This approach has worked
well for me:

1. atomic queries (one per table) let me retrieve exactly what I want from
each table.
2. they also facilitate re-use.
3. Their source is readily available.
4. The VBA code is way cleaner and more readable. In case recordset
maniplation is required, I just open the named molecular query and proceed.
In case I forgot or suddenly need another field, I just modify the source
query.
5. Even in the case where parameters are required, they are almost
invariably in the Where clause, so then I select from the named query and
add a Where clause containing the parameters.

There are a couple of other advantages too.

1. In the event that the BE needs to be migrated to SQL Server, it's a
cinch to convert the named queries to views.
2. Although the above implies a Select statement, I use the same approach
for delete and append queries: just set warnings off, execute the query,
and turn warnings back on afterwards.

Arthur


More information about the AccessD mailing list