Pathname to access and usernames in shortcut

  • Thread starter Thread starter Help
  • Start date Start date
H

Help

Hi,

We are about to deploy a database on our network (Windows/2000 servers
with Active Directory and Win2K, WinXp and Win9x clients).

The database is split front-end and back-end but both will be on a
network drive (for maintenance reasons initially, I may move the
front-end to the client machines once its stable).

We have added the security and have a .mdw file and can start it from a
shortcut.

The security is intended more to stop people accidentally
corrupting/changing things than to stop people hacking into the
database. If they want to do that they can, but they are trusted. We are
using usernames but no passwords.


I have two questions at the moment:

1) We want users to be logged in automatically with their Windows login.
I know that we can't synchronise the userid/password combinations and
that the security is different between access and active directory.
What we are thinking of is having a batch file or command file which
gets the current username from the system and then calls access (via the
same command as we would use for a shortcut) but with the username
included.

Has anyone tried this and can point me to any examples. Also, ca you see
any potential problems with this idea ?


2) The access databases and shortcut (or command file) will be on a
network drive. This means that the pathnames will need to be common. The
path to the database and .mdw file are not a problem as everyone will
have the drive already networked.
However, it occurred to me that people may have installed access in
different places on their machines. So, if the shortcut has <path to
access> as "C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" as
would be the default, that means that someone using the shortcut who has
office instaled on their D: drive wouldn't be able to use it.

So, my question is, is there a way of referring to "the place where
access is installed" in the shortcut (or the command file).

I can be sure about the location of access for the desktop machines, but
not for mobile users with their laptops.


Any advice gratefully received.

Thanks
 
Answers inline below.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm


Help said:
Hi,

We are about to deploy a database on our network (Windows/2000 servers
with Active Directory and Win2K, WinXp and Win9x clients).

The database is split front-end and back-end but both will be on a
network drive (for maintenance reasons initially, I may move the
front-end to the client machines once its stable).
Click to expand...

Maintenance of a front-end on individual user machines is much less of a
headache than the problems you can encounter if you have a shared front-end
on a network drive. You're best off to go ahead and bite the bullet and
install the front-end on the user pc's from the git-go.
We have added the security and have a .mdw file and can start it from a
shortcut.

The security is intended more to stop people accidentally
corrupting/changing things than to stop people hacking into the
database. If they want to do that they can, but they are trusted. We are
using usernames but no passwords.
Click to expand...

Are you preventing the users from changing their own passwords? If not, then
your schema below will likely not work, if someone changes their password.
I have two questions at the moment:

1) We want users to be logged in automatically with their Windows login.
I know that we can't synchronise the userid/password combinations and
that the security is different between access and active directory.
What we are thinking of is having a batch file or command file which
gets the current username from the system and then calls access (via the
same command as we would use for a shortcut) but with the username
included.

Has anyone tried this and can point me to any examples. Also, ca you see
any potential problems with this idea ?
Click to expand...

I've never tried it. You should test it and see if it works. That's the best
way I know to find out if something works. I'm not sure why that's better
than just letting the users press enter on the Access logon screen, assuming
you have prevented them from changing their passwords.
2) The access databases and shortcut (or command file) will be on a
network drive. This means that the pathnames will need to be common. The
path to the database and .mdw file are not a problem as everyone will
have the drive already networked.
However, it occurred to me that people may have installed access in
different places on their machines. So, if the shortcut has <path to
access> as "C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" as
would be the default, that means that someone using the shortcut who has
office instaled on their D: drive wouldn't be able to use it.

So, my question is, is there a way of referring to "the place where
access is installed" in the shortcut (or the command file).
Click to expand...

Again, I would say don't put the front-end on the server -- you will most
likely regret it later. I don't know if there is a way to locate the path of
a file via a batch file. The best thing to do is have your IS Department do
ALL installs of ALL programs on user PC's and then you will always know
where they are located.
 
Hi,

Thanks for your answers ... comments inline...

Lynn said:
Answers inline below. > Answers inline below.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm




Maintenance of a front-end on individual user machines is much less of a
headache than the problems you can encounter if you have a shared front-end
on a network drive. You're best off to go ahead and bite the bullet and
install the front-end on the user pc's from the git-go.
Click to expand...

Thanks for the advice.
Are you talking about locking problems with access ? or any specific
kinds of problems.

We have looked through the application to try and make sure that locking
won't be an issue and have tried to identify and remove any application
multi-user issues. Of course, we are dependent on Access doing its job ...

The main maintenance problem is that I know that I am going to have to
issue new versions of the application multiple times over the next few
weeks as people test and use it. I guess its a balance of the
inconvenience of getting users to update their version (and
hoping/checking that they do) vs. risks of running a shared front-end.
Are you preventing the users from changing their own passwords? If not, then
your schema below will likely not work, if someone changes their password.
Click to expand...

Thanks for that, its a useful comment. We will be asking users not to
change their passwords within the access database (they won't know how
to anyway). I guess if anyone does, then they get what they deserve ! :)


I've never tried it. You should test it and see if it works. That's the best
way I know to find out if something works. I'm not sure why that's better
than just letting the users press enter on the Access logon screen, assuming
you have prevented them from changing their passwords.
Click to expand...

I have just tried it and it seems to work ok using the %USERNAME%
environment variable within Win2K.
----------
@echo About to run the database as user %USERNAME%
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
"path\to\database.mdb" /WRKGRP "path\to\mdw" /user %USERNAME%
----------



The reason why its better for us is that our normal users will just go
straight into the database without seeing a user prompt and so we'll
remove the temptation for them to change it. Of course, they can change
it by setting up a new shortcut .. but they would have to be
specifically attempting to mess around then.

Again, I would say don't put the front-end on the server -- you will most
likely regret it later. I don't know if there is a way to locate the path of
a file via a batch file. The best thing to do is have your IS Department do
ALL installs of ALL programs on user PC's and then you will always know
where they are located.
Click to expand...

Ok thanks. I'll deal with it if and when it occurs.


Thanks again for your help

Cheers
 
Help said:
Hi,

Thanks for your answers ... comments inline...

Thanks for the advice.
Are you talking about locking problems with access ? or any specific
kinds of problems.
Click to expand...

You run the risk of corruption. Also in later versions you need exclusive
access to make design changes.
See
http://allenbrowne.com/ser-25.html
The main maintenance problem is that I know that I am going to have to
issue new versions of the application multiple times over the next few
weeks as people test and use it. I guess its a balance of the
inconvenience of getting users to update their version (and
hoping/checking that they do) vs. risks of running a shared front-end.
Click to expand...

You can automate updating the frontend. Have a look at Tony Toews' site for
frontend updater
http://www.granite.ab.ca/accsmstr.htm

(you'll also find great information on corruption there)
The reason why its better for us is that our normal users will just go
straight into the database without seeing a user prompt and so we'll
remove the temptation for them to change it. Of course, they can
change it by setting up a new shortcut .. but they would have to be
specifically attempting to mess around then.
Click to expand...

If you've secured it properly, then they won't be successful doing this.
 
Hi,

Joan said:
You run the risk of corruption. Also in later versions you need exclusive
access to make design changes.
See
http://allenbrowne.com/ser-25.html
Click to expand...

Thank you .. that's a very useful link ...

You can automate updating the frontend. Have a look at Tony Toews' site for
frontend updater
http://www.granite.ab.ca/accsmstr.htm

(you'll also find great information on corruption there)
Click to expand...


and again, thank you ... I'll have a play with that and use it ... the
information about Terminal Services is interesting as well and probably
explains some oddities we have been seeing.
If you've secured it properly, then they won't be successful doing this.
Click to expand...

The problem is more that we won't be password protecting the userids, so
any user could just change the command file to change the user name and
they would be that user. Its as requested by the client .. the security
we are putting in is to stop 'accidental' changes to the data by people
who shouldn't be updating...

Thanks very much for all the help

Cheers
 
Back
Top