Cannot Create WshNetwork

[Will]

We have an MS Access application that has the following code fragment:

Dim wsh as WshNetwork
Set wsh = New WshNetwork
....

At some point, creation of WshNetwowk object (second line) stopped
working on one of the computers where it had worked normally
previously. The error message says:

Automation error
The specified procedure could not be found

The unlucky computer runs Windows 2003 and MS Office 2000. The
wshom.ocx control (which, I believe, is "responsible" for WshNetwork
objects) appears to be registered properly. The user of this computer
does not remember what exactly might have happened on this computer
before the problem occurred, but it could have been
installation/deinstallation of some software, modification of some
security settings, fiddling with services, etc.

Please, advise how this problem could be debugged and, ideally, fixed.

 

[Douglas J. Steele]

Have you checked the References collection on the offending machine? It's
possible that some other Reference is broken, thus causing problems with the
reference to wshom.ocx.

On the machine(s) where it's not working, open any code module. Select Tools
| References from the menu bar. Examine all of the selected references.

If any of the selected references have "MISSING:" in front of them, unselect
them, and back out of the dialog. If you really need the reference(s) you
just unselected (you can tell by doing a Compile, under the Debug menu in
the VB Editor), go back in and reselect them.

If none have "MISSING:", select an additional reference at random, back out
of the dialog, then go back in and unselect the reference you just added. If
that doesn't solve the problem, try to unselect as many of the selected
references as you can (Access may not let you unselect them all), back out
of the dialog, then go back in and reselect the references you just
unselected. (NOTE: write down what the references are before you delete
them, because they'll be in a different order when you go back in)

 

[Norman Yuan]

Why do you need to use Windows Scripting in your Access application? Do VBA
built-in functions not do what you need? It is possible Windows scripting
engine on that Win2003 server being disabled (many network admins would
choose to disable it unless it is really needed on that server). It is
beeter to avoid using Windows scripting in Access app (or other Windows
stand-alone apps, for that matters). There is little Widows scripting can do
and VBA cannot do.

 

[David W. Fenton]

We have an MS Access application that has the following code
fragment:

Dim wsh as WshNetwork
Set wsh = New WshNetwork

I never use anything but late binding for anything other than the
main Access references (Access, VBA, DAO/ADO) except where forced to
do so.

For that reason, I never use OCX's that aren't installed by default
with Access itself.

I've used parts of the WSH in Access without an references. I don't
know if the component you're attempting to use can be used with late
binding, but your app would be much more reliable if it were.

 

[John Nurick]

Dim wsh As Object 'WshNetwork
Set wsh = CreateObject("Scripting.Network")

?

 

[Yarik]

Dim wsh As Object 'WshNetwork
Set wsh = CreateObject("Scripting.Network")

Thank you John, but this did not help.

 

[Yarik]

Hello everyone and thank you all for quick responses!

While working on them, we observed the following interesting
phenomenon:

When the similar code is placed into a VBS file and the file is
launched, everything works as it is supposed to. So WSH appears to be
working on this poor computer. However, the code in MS Access project
keeps failing regardless of whether the binding is late or early (with
the same error diagnostics).

This brings up the following question: What exactly may be different in
WSH object instantiation mechanisms used by an MS Access application
and by a VBS file launched directly?

Thank you,
Yarik.

 

[John Nurick]

Let's try to eliminate the possibility of problems with that particular
database. What happens when you create a new database file, create a
module, write or paste in some late-bound WshNetwork code (as text, not
as a module) and try to run it?

If that succeeds, it's looks as if the problem is in the database. If it
fails, the finger probably points to the Office installation: try
repairing it.

 

[Norman Yuan]

VBA->Interaction->Environ()/Environ$()

Which VBA built in function will give me the user's domain and logged in
userid?

 

[Douglas J. Steele]

Actually, I always cringe when people suggest using the Environ function to
determine the user id, since it's so easy to reset. It's far better, in my
opinion, to use the GetUserName API, as demonstrated in
http://www.mvps.org/access/api/api0008.htm at "The Access Web", or you can
use the WkStationUser API call, http://www.mvps.org/access/api/api0040.htm,
to get both domain and id.

"But", I hear the argument, "that's not a built in VBA function, which is
what I asked for!". True, but there are significant differences between
using API calls, and setting references to COM objects.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)

VBA->Interaction->Environ()/Environ$()

 

[Yarik]

Let's try to eliminate the possibility of problems with that particular
database. What happens when you create a new database file, create a
module, write or paste in some late-bound WshNetwork code (as text, not
as a module) and try to run it?

If that succeeds, it's looks as if the problem is in the database. If it
fails, the finger probably points to the Office installation: try
repairing it.

I did this experiment and the result is very surprizing: the
"brand-new", dummy ADP application works with WshNetwork just fine.

It is surprizing for me because it is the very first time I see a
corrupted ADP file that fails only on a specific computer (and works
perfectly on all other computers). If the file were indeed corrupted
I'd expect it to fail on other computers too....

BTW, as far as I know, this computer was being "tortured" by sysadmin a
lot (for security-related and other reasons), and now there are some
weird problems with other applications running on it. So at this point
it feels like it may be easier (and cheaper) just to reinstall Windows
and all other stuff on this computer (or migrate a user to another
computer which we were going to do eventually anyway)..