error 5 Invalid Procedure Call or Argument.

[JamesDeckert]

Access 2003
Front End/Back End setup. Jet Back End.

I've a program which is getting the "Invalid Procedure Call or Argument"
error. This is occuring in my autoexec routine when the program loads. I've
this program in approx 25 different businesses and a new business (who has
never successfully used the pgm) is receiving this error. Since I distribute
the Access Runtime and the pgm as an MDE, I have no way of debugging or
checking missing references. In my experience with missing references and
Access runtime, an error message is displayed stating the missing reference
prior to entering my VBA code. This is not the case in this situation as I
know the error is happing within my Autoexec function. My error msg states
the err.number, err.description and function name.

The autoexec function is fairly long and I can't narrow down where in the
routine the error is happening.

I've looked at Microsofts' help for this error and none of the solutions
"look" right. The pgm has been uninstalled (as well as Access) and
reinstalled to no avail.

Any general principals which may help me in narrowing down where the problem
is?

thanks for any input.
James

 

[Tom Wickerath]

Hi James,

Have you tried the suggestions found in Access MVP Doug Steeles article?
http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

"What you can try and do is ensure that the same referenced files exist on
all workstations. On the workstation where the application was developed,
open up the MDB that was used to create the MDE. Run the following code to
determine all of the required references:"

I would also try to make sure that the DAO and ADO libraries are properly
registered on the machine that is giving the problems. Click on Start > Run.
Then enter the commands:

Regsvr32 "C:\Program Files\Common Files\system\ado\Msado15.dll"
Regsvr32 "C:\Program Files\Common Files\Microsoft Shared\DAO\Dao360.dll"

Note: You'll need to first verify that the paths shown above are correct.

You might as well do this one at the same time:
Regsvr32 Accwiz.dll


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

 

[JamesDeckert]

Thanks Tom,
I'll work my way through the advice.

Though I think it could be a missing reference (it seems like it would have
to be something specific to that computer - not my software), I recall
several months ago testing for a missing reference within a database as the
first thing when it loaded. Then I put the database on a computer using the
runtime. What happened is that a Microsoft error message displayed, not the
message box I formatted to be displayed on missing references. From this
experiment, I came to the conclusion that a database using the Access runtime
would not even begin to execute unless the references were not "missing".

The error I'm getting in this case is within one of my functions which makes
me think that there are no missing references.

Anyway, I'll pursue the Regsvr32 commands as you suggest (as well as the
Doug Steele article) and see if anything changes.

thanks for the help,
James

 

[Tom Wickerath]

Hi James,

For the new business, who has never successfully used the program, I would
also verify that they have MDAC 2.8 (Microsoft Data Access Components)
installed on each PC. You can use the MDAC Component Checker Utility to help
verify this:

Component Checker: Diagnose problems and reconfigure MDAC installations
http://support.microsoft.com/?id=307255

What happened is that a Microsoft error message displayed, not the
message box I formatted to be displayed on missing references. From this
experiment, I came to the conclusion that a database using the Access runtime
would not even begin to execute unless the references were not "missing".

The results of your experiment may have led you to the wrong conclusions,
although mde's are apparently more fault tolerant when compared with mdb's.
Take a look at what Michael (MichKa) Kaplan has to say on the subject.
(MichKa is a current Microsoft employee, and a former member of the Access
Development Team).

http://www.trigeminal.com/usenet/usenet026.asp?1033


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

 

[JamesDeckert]

Hey Tom,
Thanks so much for the help. Here is what I've found.
Component Checker: shows "MDAC 2.8 SP1 ON WINDOWS XP SP2"
using Regsvr32 on Msado15.dll was successful
using Regsvr32 on Dao360.dll was successful

At this point I still had the error.

showing all references from the ListReferences() function you pointed me to
gave the following information.
VBA: C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL
Access: G:\Program Files\Microsoft Office\OFFICE11\MSACC.OLB
stdole: C:\WINDOWS\system32\stdole2.tlb
DAO: C:\Program Files\Common Files\Microsoft Shared\DAO\dao360.dll
ADODB: C:\Program Files\Common Files\System\ADO\msado21.tlb
Office: C:\Program Files\Common Files\Microsoft Shared\OFFICE11\MSO.DLL
ADOX: C:\Program Files\Common Files\System\ADO\msadox.dll

I then registered Accwiz.dll and msadox.dll and my program came up fine at
this point. So it was one of these last two files that was the problem.

Thanks so much for the help

James Deckert

 

[Tom Wickerath]

Hi James,

That's good to hear that the problem is fixed! Thanks for reporting this
back.

One question: Have you verified that you really need all of the references
that you indicated? Any that you can eliminate, and still get your code to
compile, are not required. Another option to look into is converting early
bound code (requires a checked reference) into late bound code (does not
require a checked reference). So, you might very well be able to eliminate
the references to the ADOX and Office libraries, or at the very least,
convert dependent code to use late binding instead.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

 

[JamesDeckert]

Tom,

Which of the following references are going to be problems when changing
operating systems, or new versions of Access? (i.e. which should be removed
and late binding used)
VBA: C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL
Access: G:\Program Files\Microsoft Office\OFFICE11\MSACC.OLB
stdole: C:\WINDOWS\system32\stdole2.tlb
DAO: C:\Program Files\Common Files\Microsoft Shared\DAO\dao360.dll
ADODB: C:\Program Files\Common Files\System\ADO\msado21.tlb
Office: C:\Program Files\Common Files\Microsoft Shared\OFFICE11\MSO.DLL
ADOX: C:\Program Files\Common Files\System\ADO\msadox.dll

Did you check your Desktop Developer's Handbook? The discussion about late
binding is not long (3 pages), but kind of long for me to regurgitate here.

thanks,
James Deckert

 

[Tom Wickerath]

Hi James,

It is impossible to uncheck the first two references in the list, for VBA
and Access. Of those you show in the list, I'd try to eliminate the need for
checked references to the last three: ADODB, Office and ADOX.

Did you check your Desktop Developer's Handbook?

I forgot to do that last night. I'll try to remember to do it tonight.
However, the only advantages that I can think of regarding early binding
include Intellisence and slightly faster code execution, but I'm not sure the
speed improvement would be all that noticeable on a modern PC.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

 

[Douglas J. Steele]

I forgot to do that last night. I'll try to remember to do it tonight.
However, the only advantages that I can think of regarding early binding
include Intellisence and slightly faster code execution, but I'm not sure
the
speed improvement would be all that noticeable on a modern PC.

Agreed. Even when I have the luxury of a standard desktop, where I know
every user will have the same versions of Office, I use Late Binding so as
to avoid having to add additional references. I've yet to see any
performance differences.

 

[JamesDeckert]

Tom and Douglas,
thanks for the input.

The handbook comes down to these 3 reasons.
1. Speed
2. VBA editor support
3. Online help
But what it doesn't do is suggest removal once the code is developed. I seem
to notice a lack of "real-world" application suggestions in most books. Few
books discuss how the run-time differs from the full version.

Thanks for your help, and thanks for all the work you both do on this site.
James Deckert

 

[Tom Wickerath]

Hi James,

I brought my copy of the Access 2002 Desktop Dev. Handbook into work with me
today, but it's still sitting on my desk with the pages marked for reading...

The handbook comes down to these 3 reasons.
1. Speed
2. VBA editor support
3. Online help

That's why I advocate using early binding when developing / debugging code,
but then switching it over to late binding for production use. It's usually
just a matter of commenting out one or two lines of code, and uncommenting
one or two other lines of code, in order to make the switcheroo. For example:

' Late Binding
Dim accessApp As Object
Set accessApp = CreateObject("Access.Application")

' Early Binding
Dim accessApp As Access.Application
Set accessApp = CreateObject("Access.Application")

In this case, you simply comment out two lines of code, and leave the other
two lines of code uncommented, depending on whether you are
developing/debugging and want Intellisence to work.

Here are a few KB articles that you may find helpful:

INFO: Troubleshooting Error 429 When Automating Office Applications
http://support.microsoft.com/kb/244264

This article includes the following:

"If the problem occurs only when the object is early-bound, the problem is
with the server application, and can typically be corrected by reinstalling
the application (see later)."

This suggests an additional reason (user's application is not properly
registered) that late binding may help to overcome.

INFO: Using Early Binding and Late Binding in Automation
http://support.microsoft.com/kb/245115/

This KB article recommends early binding due to the speed and Intellisense,
ie. "In terms of overall execution speed, it is at least twice as fast as
late binding", but with modern hardware, twice as fast as, say, 40
milliseconds, is 20 milliseconds. Are you going to be able to tell the
difference? That's a somewhat facticious example, since I have no actual
quantitative data on actual execution speeds.

Thanks for your help, and thanks for all the work you both do on this site.

You're welcome! I know that I personally learn a lot by helping other
people. Plus, I enjoy the challenges in trying to solve problems.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________