I have several Excel 2003 application that reference a VB6 COM .dll that
contains a bunch of business logic and sp calls to SQL server. This all
works fine in our development environment. Things got a bit dicier when
trying to deploy the application at a client site. The Excel applications
work fine and are utilizing the .DLL to read and write data from SQL. The
problem comes up in the Workbook_BeforeClose event where the code looks
somewhat like this:

Private Sub Workbook_BeforeClose()

Dim tio as new CustomClientDLL.XClass
if (not tio.Cleanup()) then ' Error is thrown here
MsgBox tio.ErrorMessage
Endif

End Sub

And in the clients environment the tio.Cleanup call throws error 438
(doesn't support method or property). I would normally chalk that up as an
unregistered .DLL or earlier version of the .DLL that did not yet have that
method, but this was installed on a 'clean' machine, and the Excel
application was able to retrieve data using the .dll -- so the application is
using the .DLL earlier on.

A little playing around in the development environment shook my confidence a
bit as one of the applications should a similar behavior, instead throwing a
Error 430. Oddly enough, if a breakpoint was set at this line -- executing
the command in the immediate window works just fine. Comparing this
application to the others th work in the dev environment -- the only
difference was in the references section had the Office 11.0 object library
set higher in priority than the Forms 2.0 Object library. Swapping those two
immediately cured the problem in the development environment -- this has not
yet been tested in the client environment. Since I could not even begin to
explain why this ordering would matter at all, I decided to post here since I
have alot of experience with VB6 and C#, but relatively little with Office
applications. So the question really is -- is there anything obviously
wrong, and how should I approach debugging this remotely at the client site?
I have told that we are using the same version and service packs for Windows
XP and Office. It is particularly perplexing since the problem is
apparently isolated to the exit event.

Thanks for any suggestions up front!

Bob