Property for Workgroup Information File?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Looking for a place that I can call in a VBA procedure that will return the
current Workgroup Information File name. I tried the DAO object SystemDB,
but it always returns "System.mdw" even after I've joined a differently-named
Workgroup file and restarted the app, etc.

The ultimate functionality I'm looking for is for a startup procedure to
check the current workgroup file, and if it doesn't match what I define as
the correct one, it'll prompt the user to provide the correct path for the
one I want them to use. I figured this'd be a good way to help improve the
database's security/usability without me having access to developer's tools.
The sticky wicket is that I can't figure out how to return the current
workgroup name...

On a related note, how do I set up a function or procedure to run as part of
the OnLoad event (if there is one, or the equivilant) for the database
itself? I'm thinking of both the above function and tossing in the
ubiquitous AllowByPassKey = False dealie.
 
dbengine.systemdb should work. Is that the exact syntax you are
using?

If that doesn't work (but it should), there's a syscmd constant:
syscmd(acsyscmdgetworkgroupfile), or somesuch.

However, understand that you can not *change* the workgrop file for the
current instance of Access, once it has started running. You can only
dispay a message, then quit Acess & wait for him to try again.

HTH,
TC
 
And BTW, AllowByPassKey changes only take affect the *next* open of the
database. They do not affect the current open. So your plan for
changing that value on daabase open, will not work the way you expect.

HTH,
TC
 
Paul said:
The ultimate functionality I'm looking for is for a startup procedure
to check the current workgroup file, and if it doesn't match what I
define as the correct one, it'll prompt the user to provide the
correct path for the one I want them to use. I figured this'd be a
good way to help improve the database's security/usability without me
having access to developer's tools. The sticky wicket is that I can't
figure out how to return the current workgroup name...
Click to expand...

Further to TC's comments, you shouldn't need to do this. If you implement
security properly, then they won't even be able to open your database
without using the correct mdw. If they can, then you missed a step in
securing it.
 
Thanks for the info, TC, on both counts. The systemDB syntax; I tried two
different ones, both based on what 'should' have worked by the help file.
SystemDB by itself returned System.mdw, as did CurrentDB().SystemDB. I tried
your syntax and it worked perfectly, thanks.

As for the AllowByPassKey change, if I understand you properly, I should
only have to open the DB once after making that change, and all subsequent
openings should stay at my setting, right?

Lastly, still looking for where to put the functions I want to run on
opening; that is to say, how to get them to run when the DB opens. Thanks
for your help so far!
 
Paul said:
Thanks for the info, TC, on both counts. The systemDB syntax; I tried two
different ones, both based on what 'should' have worked by the help file.
SystemDB by itself returned System.mdw, as did CurrentDB().SystemDB. I tried
your syntax and it worked perfectly, thanks.
Click to expand...

No probs :-)

As for the AllowByPassKey change, if I understand you properly, I should
only have to open the DB once after making that change, and all subsequent
openings should stay at my setting, right?
Click to expand...

Yes. But this means that you can't effectively control that setting by
checking currentuser() on database open. The *previous* value of that
setting has already been used (to determine whether to allow the bypass
key or not) *before* any database open events are run.

Lastly, still looking for where to put the functions I want to run on
Click to expand...
opening; that is to say, how to get them to run when the DB opens. Thanks
for your help so far!
Click to expand...

Create a standard module. Put a public function in that module; for
example:

public function start_me_up()
msgbox "I have started up!"
end function

Then go to Tools:Startup and enter that function name in the right spot
on the screen provided. (I can't remember the name of at spot. It will
be obvious. Go to it then press F1 for further help.)

PS. Joan made a spot-on comment about the workgroup file. There are
some very rare cases where you might want to check which workgoup file
is in use, but yours is not one of them. As Joan rightly said, if they
can open your secured db with the wrong workgroup file, then, the db
has not been properly secured.

HTH,
TC
 
Well, thanks for the observation. I actually didn't know that (in my
previous experience, folks could open the DB w/ the System.mdw). Apparently
I missed a step in securing the DB... Not sure which one.

In any case, the functionality I'm looking for is as follows. I'm creating
the database w/o current knowledge of what the path will be to the workgroup
file once it's installed on client machines (I plan on the workgroup file
residing on the server w/ the backend, but I don't yet know what the file
path will be for every client, or if it'lle ven be the same path). What I
was thinking of as a solution is to have the system check the current
filename against the filename that I know I'm naming the workgroup file. If
it returns correctly, the app loads as normal. If it doesn't return
correctly, then I was debating either running a filesearch in the background
for the appropriate .mdw, or else prompting the user to enter the correct
path to the required .mdw. Or a combination (search, then prompt if the
search returns as a fail.)

I planned on using a similar check to look for the backend tables on startup.

Am I way off base here? I've done a fair amount of access development, but
this'll be my first foray into a client/server setup.
 
Paul Vencill said:
Well, thanks for the observation. I actually didn't know that (in my
previous experience, folks could open the DB w/ the System.mdw). Apparently
I missed a step in securing the DB... Not sure which one.

In any case, the functionality I'm looking for is as follows. I'm creating
the database w/o current knowledge of what the path will be to the workgroup
file once it's installed on client machines (I plan on the workgroup file
residing on the server w/ the backend, but I don't yet know what the file
path will be for every client, or if it'lle ven be the same path). What I
was thinking of as a solution is to have the system check the current
filename against the filename that I know I'm naming the workgroup file. If
it returns correctly, the app loads as normal. If it doesn't return
correctly, then I was debating either running a filesearch in the background
for the appropriate .mdw, or else prompting the user to enter the correct
path to the required .mdw. Or a combination (search, then prompt if the
search returns as a fail.)

I planned on using a similar check to look for the backend tables on startup.

Am I way off base here? I've done a fair amount of access development, but
this'll be my first foray into a client/server setup.
Click to expand...

You would need to use two apps since your secured app can only be launched using
the secure MDW then you need a first app that doesn't require the MDW to locate
it and then launch the second app with it.
 
Ah! Hadn't thought of that, thanks for the help. You know, after all this
thinking and questioning, it occurs to me that the easiest solution might
simply be to make sure the users (or local IT guys) are properly trained in
setting up the /wrkgrp switch on the shortcut...<rolleyes> Thanks for the
help, though, again... it's been educational.

:
 
Back
Top