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.

--
Will

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)

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)


"Will" <westes-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>
> --
> Will
>
>

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.

"Will" <westes-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>
> --
> Will
>
>

"Will" <westes-(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> 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.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

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

?

On Sat, 20 Jan 2007 21:26:41 -0800, "Will" <westes-(E-Mail Removed)>
wrote:

>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.

--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.

"Norman Yuan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.

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

--
Will

John Nurick wrote:
> Dim wsh As Object 'WshNetwork
> Set wsh = CreateObject("Scripting.Network")

Thank you John, but this did not help.

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.


Will wrote:
> 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.
>
> --
> Will

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.



On 22 Jan 2007 19:32:01 -0800, "Yarik" <(E-Mail Removed)> wrote:

>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.
>
>
>Will wrote:
>> 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.
>>
>> --
>> Will

--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.

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

"Will" <westes-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Norman Yuan" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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.
>
> Which VBA built in function will give me the user's domain and logged in
> userid?
>
> --
> Will
>
>