Some pointers, if you please. First, it makes your code more readable if you use code tags and indentation. Plus, forums often insert a space after a set number of characters, so you could end up with words split and not notice. Then we are commenting on something that doesn't really exist. Not sure if this forum does.
- you don't seem to be using any of these variables, so why declare them?
Dim MyFolder2 As String
Dim DQ As String
Dim MyData As String
Dim myQueryName As String
Dim myExportFileName As String
- you only need to turn off warnings once in a procedure and they remain off
- you need to turn them back on! All other procedures that run afterwards are affected. Not sure if this is reset when the affected db closes and reopens.
- there is no error handler in your procedure. Should it err out, warnings remain turned off even if you have written to turn them on IF this is not written to happen after dealing with an error.
- it has been said by Access gurus much smarter than I that if you do not have Option Explicit in every module, you deserve what you get. I agree. The default setting is to turn off "Require Variable Declaration". I always turn it on.
- rtn and varFile are undeclared variables
- the date is a text value?? ('" & Date & "')
- opening, then immediately closing a query can produce inconsistent results. IIRC, the expression service can run asynchronously with Access JET. This means code can continue before other things finish, in some cases. If you can, I would open a query, then close it at the end of the whole process. If not, a pause might be a good idea, even if for only one or two seconds.
- you should destroy all objects that have been SET (fdialog)
- I would not write anything that did not relate to an object or property inside a With block (like running queries). You're basically saying, With the dialog, set or do this and this to it. The rest is not related to the dialog, so it really shouldn't be in there. It's just better form and will make your code easier to follow; not just for others, but for you too when you come back to this months from now. Besides, you'll appear more astute as a code writer!
How I would write a typical error handler, where this follows my Dim statements: On Error GoTo errHandler
At the end of the procedure stuff that performs the task, a line lable:
exitHere:
Now clean up, like -
turn on warnings;
close recordsets, queries;
destroy objects (SET to Nothing), then
Exit Sub (or Function, else code execution will continue to the error handler). Then,
errHandler:
msgbox "Error " & Err.Number & ": " & Err.Description (result like Error 91: Invalid use of Null)
Resume exitHere (this will direct to the exitHere line, to clean up. If there is no error, cleanup still occurs after the exitHere line label, and the Exit Sub line terminates code).