Unwelcome Password requests (1 Viewer)

Rats

Registered User.
Local time
Today, 19:55
Joined
Jan 11, 2005
Messages
151
I have a project that is made up of one main database supplying data to two other databases. Normally it works fine. I have installed it on some PC's belonging to our companies agents and in most cases it works fine as well. However, in some cases when one of the smaller databases is opened, often several days after a successful install, the user is prompted for a password (there is none attached to the database). Obviously the database will not open without it (the password). In these cases I replace the database with a copy and it works fine again. I have read in the forum that similar problems have been caused by a problem with the System.MDW file and that it should be replaced with a clean copy. I am not clear on this point. Is my copy clean and they have a faulty one or am I inadvertantly creating the problem on their computer.
As I said before it works fine in our office and most others. Just one or two have this problem. Any suggestions on how I could fix it please?:confused:
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 06:55
Joined
Feb 28, 2001
Messages
27,172
The system.mdw file is created by Office when you install it. You also have an entry pointing to it in the registry, which is machine-specific. But you never see the creation of that pointer because it is a silent operation handled by the installation process.

When you join a workgroup, you update the registry entry on THAT ONE MACHINE. Thereafter, you need a password for your account to open another DB because MS Windows is too stupid to realize you weren't opening the database related to the most recent workgroup you joined.

Try having the person just rejoin to their "base" workgroup. Alternatively, ALWAYS have them join to a copy of the "right" workgroup in the same folder as the DB in question. It is possible to define an icon that includes the explicit workgroup name as part of the implied command line. You can look this up using the help files for "command line options" or something like that.
 

Rats

Registered User.
Local time
Today, 19:55
Joined
Jan 11, 2005
Messages
151
Thanks Doc Man. I compared Workgroup Admin settings on the Client PC and compared them to my PC where the database had been built. My System.MDW address is c:\Program Files\Common Files\System\System.MDW and on the Client PC it is c:\Documents & Settings\clientsrealname\Application Data\Microsoft\Access\System.MDW.
1. Would this be causing the password request problem. If so why on just one of my databases and not on all three of them?
2. To fix it could I make a copy of my System.MDW file and add it to the same location on their computer as it is on mine?
3. A common denominator in the clients I am experiencing this problem with seems to be that they had Office 2000 and upgraded to Office 2003.

Hope you can help?

Thanks again

Peter
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 06:55
Joined
Feb 28, 2001
Messages
27,172
The more common denominator is that you DIDN'T rename SYSTEM.MDW for your specific project to some name more closely related to that project. You will have a hard time figuring out WHICH of the many possible SYSTEM.MDW files you were connected to.

The path difference is indicative that NEITHER user is using the same MDW file; instead, they look like BOTH are connected to the original MDW created by Office installation. So what you get is a bad case of OHNKWTOHID. (Forgot your acronym dictionary? One Hand Not Knowing What The Other Hand Is Doing.) The MDW files, being separately created and not necessarily copies of one another, have diverged in their history so that you cannot clearly say to what projects they belong.

Search this forum for tips on "Security" "Securing a Database" "WorkGroup" and other similar topics to get more detailed discussions of how to properly share a workgroup file so that everyone always uses the right one and CAN'T use the wrong one.
 

Rats

Registered User.
Local time
Today, 19:55
Joined
Jan 11, 2005
Messages
151
I have not intentionally set any workgroup permissions for this database and just used the default settings as the program is mainly being used by single use Agents. Most of our Clients are not having this problem. I am more than happy to reload the database on the ones that are having the problem as at the moment it is unuseable.
Is there a change I can make at my end that would rectify the problem at their end?
Hope you can help as I have some stroppy clients at the moment.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 06:55
Joined
Feb 28, 2001
Messages
27,172
It is not that you have set any permissions. It is that they access some other DB that has, but don't remember to rejoin the right workgroups. Remember, Windows is DUMB about knowing what you really wanted to do.

The EASIEST way to assure the right result first time every time is

1. Make a "good" copy of the SYSTEM.MDW file that works with the DB.

2. Copy it to the folder that holds the DB.

3. Change the name from SYSTEM.MDW to MYPROJECT.MDW

4. Create a new icon to open your database.

5. Now look up the command-line option to specify an MDW file.

6. Edit the properties of the icon to contain the mdw specifier with the name of the (now renamed) .MDW file.

7. Tell your users to copy that icon to their desktops.
 

Rats

Registered User.
Local time
Today, 19:55
Joined
Jan 11, 2005
Messages
151
Thanks Doc Man. Thats great having those steps as I can just make a new copy for these clients with those instructions and hopefully fix the problem.
I appreciate your patience.
Cheers
Peter
 

Rats

Registered User.
Local time
Today, 19:55
Joined
Jan 11, 2005
Messages
151
Hi Doc Man
Further to my last message. The Database I am having the problems with is opened by clicking a button in my main database which runs the following code
Code:
Private Sub Command14_Click()
On Error GoTo Err_command14_Click
'MsgBox "Now opening the MAP Planner Program", vbOKOnly, "MAP Planner"
    Application.FollowHyperlink DLookup("[Link]", "links", "[linkname] = 'DebtProjector'")

Exit_command14_Click:
    Exit Sub

Err_command14_Click:
    MsgBox Err.Description
    Resume Exit_command14_Click
End Sub
The "DebtProjector" link is as follows
Code:
"C:\Master Achiever Program\Debt Projector\DebtProjector.mdb"

Following your previous help I set up a shortcut to open the MAPnew.mdb (the main database) but as I dont use a shortcut apart from the hyperlink to open the problem database I am not sure how to implement your directions in this case. Below is the code I used in the shortcut following directions found in the MKB on this link http://support.microsoft.com/?scid=kb;en-us;305542&spid=2509&sid=307

"C:\Master Achiever Program\MAPnew.mdb" /wrkgrp "C:\Master Achiever Program\map.MDW"

Would it be possible to alter the "DebtProjector" link to enable the same function as the code used in the shortcut. I tried adding the code but on activation of the hyperlink got a error message "Cannot locate the Internet server or proxy server"
Code:
C:\Master Achiever Program\Debt Projector\DebtProjector.mdb/wrkgrp C:\Master Achiever Program\map.mdw

Thanks again
Peter
 

gijskerstens

New member
Local time
Today, 13:55
Joined
Mar 10, 2006
Messages
6
Code:
"C:\Master Achiever Program\Debt Projector\DebtProjector.mdb"
/wrkgrp "C:\Master Achiever Program\map.mdw"
looks like you forgot a space between the .mdb and /wrkgrp
and the part after /wrkgrp should be in quotes, AFAIK
 
Last edited:

Rats

Registered User.
Local time
Today, 19:55
Joined
Jan 11, 2005
Messages
151
Solution Found

I would like to thank The Doc Man and all others that tried to help with this problem.
Turns out the problem was not related to Workgroups etc. it was caused by by something within the Office program loaded on the individual PC's.
3. A common denominator in the clients I am experiencing this problem with seems to be that they had Office 2000 and upgraded to Office 2003.
In each instance the client had a "hybrid" office set up ie still had Office 2000 and Office XP components or Office XP and Office 2003 components. For example the last client had Office XP installed but not upgraded to the latest Service Pack. Their IT guy had installed a new server and added Outlook 2003 to their PC's.
We deleted Outlook 2003, ran the Office Updates check which installed the Service Packs and Lo and behold the problem vanished. Tried the same thing with another client who had Word 2000 but Office XP. Uninstalled Word 2000, ran the updates and same success.

I still dont know why the problem was occurring but at least I now know how to fix it.
Thanks again everyone.
 

Users who are viewing this thread

Top Bottom