By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,490 Members | 1,772 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,490 IT Pros & Developers. It's quick & easy.

Access Login no longer working

P: n/a
A few years ago I deployed an MS Access DB, users used to have a login
and pword to get into the DB.

I now migrated the DB to an Advanced Server 2003.

Question 1. The problem is that the DB no longer authenticates (uname
&pword). Is this a flaw in Advanced Server?

Question 2. How can I fix it?

Question 3. Are there any RAD tools that would basically convert the
MSACCESS application to a WebApp without doing too much PHP, SQL code?
Oct 3 '08 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Answer 1. If the db isn't asking for identification and still lets the user
open the db and work with it, that means the db was never secured properly.
If it's blocking users from opening the db, that's good, it's doing its job.
The users aren't using the secure workgroup file they used to use, that's why
they're not getting prompted.

Answer 2. If the db wasn't secured properly read and study the security faq
and secure the db again.

http://support.microsoft.com/kb/207793

If the db was secured properly give each user a shortcut to open the db:

"path to msaccess.exe" "path to db" /wrkgrp "path to secure.mdw"

Answer 3. I don't know of any.

Chris
Microsoft MVP
cubangeek wrote:
>A few years ago I deployed an MS Access DB, users used to have a login
and pword to get into the DB.

I now migrated the DB to an Advanced Server 2003.

Question 1. The problem is that the DB no longer authenticates (uname
&pword). Is this a flaw in Advanced Server?

Question 2. How can I fix it?

Question 3. Are there any RAD tools that would basically convert the
MSACCESS application to a WebApp without doing too much PHP, SQL code?
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200810/1

Oct 3 '08 #2

P: n/a
On Fri, 03 Oct 2008 22:07:12 GMT, "Chris O'C via AccessMonster.com"
<u29189@uwewrote:

One way this could happen is if the user was starting the app from a
shortcut that includes the /user and /password command line switches.

-Tom.
Microsoft Access MVP

>Answer 1. If the db isn't asking for identification and still lets the user
open the db and work with it, that means the db was never secured properly.
<clip>
Oct 4 '08 #3

P: n/a
This is true, but do you really think the developer who implemented user
level security would be aware the users aren't actively authenticating, but
unaware that they know how to make the Access db even less secure than he/she
created it, and now all users use the /user and /pwd command line switches in
Windows shortcuts since the network server has been upgraded?

Chris
Microsoft MVP
Tom van Stiphout wrote:
>One way this could happen is if the user was starting the app from a
shortcut that includes the /user and /password command line switches.
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200810/1

Oct 4 '08 #4

P: n/a
On Sat, 04 Oct 2008 16:15:48 GMT, "Chris O'C via AccessMonster.com"
<u29189@uwewrote:

Agreed. Of course not. I just wanted to point out that there is a way
to get into a secured application without being prompted for u/pw.

-Tom.

>This is true, but do you really think the developer who implemented user
level security would be aware the users aren't actively authenticating, but
unaware that they know how to make the Access db even less secure than he/she
created it, and now all users use the /user and /pwd command line switches in
Windows shortcuts since the network server has been upgraded?

Chris
Microsoft MVP
Tom van Stiphout wrote:
>>One way this could happen is if the user was starting the app from a
shortcut that includes the /user and /password command line switches.
Oct 4 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.