tags:

views:

417

answers:

5

I am trying to output multiple tables to excel files. Every time I run the macro it prompts me to overwrite the old file. I am looking for a method that doesn't involve send keys because it locks the keyboard and mouse until the macro completes.

What would the best solution be?

+1  A: 

Have another macro that runs first and deletes the file if it already exists.

Neil Barnwell
There isn't an option to delete an external file.
`Kill [PathToFile]` will delete the external files, but you'll need to handle the error that's generated if the file isn't there.
A. Scagnelli
A: 

Not sure about Access, but most other Office applications have a DisplayAlerts property or something similar, so you can do Application.DisplayAlerts = False before doing operations that normally cause a dialog to appear.

Gary McGill
I tried that. It only suppresses the internal prompts. It doesn't work when exporting.
+3  A: 

Are you using DoCmd.OutputTo?

 DoCmd.OutputTo acOutputTable, "Table1", acFormatXLS, "c:\temp\test.xls"

This doesn't appear to prompt to overwrite existing files.

pjp
I like this answer, except I wish that OutputTo would let you set the version of Excel it was exporting too.
CodeSlave
+3  A: 

You can do something like this, but it's cludgy and not very robust.

DoCmd.SetWarnings False
'do stuff
DoCmd.SetWarnings true

What you could also do is first see if the file is there, and then if it is, delete it (of course this destroys any special file permissions you had set on it).

If Dir(strPath) <> "" Then
    Kill (strPath) 'Delete (strPath)
End If
DoCmd.TransferSpreadsheet acExport, _
                            acSpreadsheetTypeExcel8, _
                            "MyTableQueryName", _
                            strPath, _
                            True
CodeSlave
+1 for the second set of code
KevenDenen
Setting Setwarnings off, is always a pretty bad idea. It's basically a way of ignoring error reports from Access, and you don't know for certain what particular issues you end up ignoring.
David-W-Fenton
DWF, agreed. As I said, it's cludgy
CodeSlave
I agree, don't use the first option. But the second one is good. You probably should have split this into two answers :)
apenwarr
A: 

I suggest you get away from using macros as soon as possible. They are not robust (no error handling) and not manageable (how do you figure out where a macro is supposed to be used?).

DoCmd.OutputTo or one of the DoCmd.TransferXXX commands is going to be much eaiser to deal with in the long run.

David-W-Fenton