Workgroup Connection Lost

[Guest]

We have started installing Windows XP with Access 2003 on user machines.
Whenever one of these machines lose connection to the network while working
in MSAccess 2000 database the Workgroup connection switches from our shared
workgroup to the default workgroup on the user machine.

This does not happen to users of Windows NT and Access 2000.

Why is this happening and how can we prevent it from happening?

Thanks for any information that can be provided!

 

[Scott McDaniel]

We have started installing Windows XP with Access 2003 on user machines.
Whenever one of these machines lose connection to the network while
working
in MSAccess 2000 database the Workgroup connection switches from our
shared
workgroup to the default workgroup on the user machine.

When you say it "switches to the default workgroup on the user machine", how
do you verify this? Far as I know, you can't switch workgroups unless you
close/reopen Access and tell Access which workgroup to use

 

[TC]

If you open a database by double-clicking the mdb file, Access uses the
default workgroup file for that PC. This will be the system.mdw that
was installed as part of Access, or some other workgroup file that you
have made the default, by using the workgroup administrator program or
function.

Alternatively, if you open a database by using a shortcut with the
/wrkgrp switch, Access will use the workgroup file that is specified by
that switch.

There is no persistent "connection" to a workgroup file, and losing the
newtwork will not cause the workgroup file to "switch" - whatever you
mean by that.

HTH,
TC

 

[TC]

Um, when I say that there is no persistent connection to a workgroup
file, I am not referring to whether the workgroup file is or isn't kept
open while the database is in use. It is kept open. I'm referring to
whether there is a pre-defined relationship between a database and a
workgroup file, such that this relationship could be "broken", or
somehow "switch". There isn't!

TC

 

[Guest]

When we go to Tools, Security, Workgroup Administration it no longer points
to the shared system.mdw

 

[Guest]

That's odd though because it works until the connection is lost. The users
will open msaccess applications several times a day over several days and the
connection to the shared mdw file remains (by this I mean if you look under
Tools Security Workgroup Administration you can see the address for the
shared mdw). It only changes to default mdw when a users connection is
dropped for any reason (by this I mean if you look under Tools Security
Workgroup Administration you can see the addess for default mdw on user
machine).

I wanted to avoid shotcuts as our file names change with every release but
it sounds like the only thing that will work. I will try it!

Thanks for the help!

 

[Joan Wild]

When we go to Tools, Security, Workgroup Administration it no longer
points
to the shared system.mdw

That doesn't tell you the workgroup file in use. That tells you what your
default workgroup is. If it's set to system.mdw, but you use a shortcut
that specifies a different workgroup via the /wrkgrp switch, the Workgroup
Administrator will still tell you system.mdw.

To confirm the mdw *in use*, hit Ctrl-G and type ?DBEngine.SystemDB

 

[TC]

Is this correct? : You use the workgroup administrator program or
function, on a PC, to change the default workgroup, for that PC, to the
workgroup file on the server. If you go back to the workgroup program
or function later, on that PC, it still shows the workgroup file on the
server. But if the network connection is lost, while the application is
running, & you go back to the workgroup adminuistrator program or
function, on that PC, it now shows the default workgroup file as being
the one on that PC - not the one on the server?

Sorry, I still can't see that hapenning. The name & location of the
default workgrouop file for the PC, is stored in a registry key on that
PC. I can't see anything changing that registry key, except manual use
of the workgroup administrator program or function.

There must be something you aren't seeing &/or telling us!

HTH,
TC