Yes, Bob, I read your post and read the site you posted.
First, thanks for letting me know about Analyze with Excel.
But, I would not recommend doing it that way. First, it is a poor
implementation of Automation. There are serious problems with the posted
solution. It does not quit the Xl application, so it will be left running.
It explicitly uses CreateObject which, if the user already had an instance of
Excel running could confuse Access and maybe close the user's instance and
loose her work. And, there would be no column headers.
And lastly, why go to all that trouble when a simple TransferSpreadsheet
would work?
I suggest you rewrite your code.

Signature
Dave Hargis, Microsoft Access MVP
>But, I would not recommend doing it that way. First, it is a poor
>implementation of Automation.
I and many others would disagree with you on that one.
>There are serious problems with the posted
>solution. It does not quit the Xl application, so it will be left running.
If closed the application closes so the user would have to reopen the
spreadsheet and that is not what they wanted. They wanted the same
functionality as the Analyze with Excel button which sends it to Excel and
opens it.
>It explicitly uses CreateObject which, if the user already had an instance of
>Excel running could confuse Access and maybe close the user's instance and
>loose her work.
In 10 years of using this like this I have NEVER had that problem.
>And, there would be no column headers.
Which can be implemented easily enough by iterating through the field names
>And lastly, why go to all that trouble when a simple TransferSpreadsheet
>would work?
Depending on the complexity of the filtering that is being done on the form,
it may take more work to build the query instead of just taking the recordset.
>I suggest you rewrite your code.
Well, I disagree...

Signature
--
Bob Larson
Access World Forums Super Moderator
Utter Access VIP
Tutorials at http://www.btabdevelopment.com
__________________________________
Access 2000, 2002, 2003, 2007