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