Access security glitch

[ginnyk]

I have a client using an mde created in 1999 by someone else, for
which I don't have the original source. There is a workgroup file that

accompanies the mde file. I have the user and password information
required by the workgroup file.
In 2004 the client requested changes. Without the source, I
couldn't make the change to the mde file itself, so I wrote a small mdb

that attaches tables and provides a form to fulfill the client's new
requirements. I created a shortcut for the new mdb that includes the
workgroup info, and for 2 years everything has worked fine.
Suddenly, the client is getting permission errors whenever he
attempts to access his data. He can open my tool mdb, but not the
tables attached to it. As it works fine when re-installed on my
desktop, I figured his copy of the workgroup file had been corrupted or

overwritten. I sent him a replacement, but it didn't help.
Any ideas on where the permission errors might be coming from would
be greatly appreciated.

 

[Guest]

The first things that I would check are the drive mappings or file/folder
permissions. Somebody could have messed with them. Next I would relink the
attached tables.

 

[ginnyk]

The first things that I would check are the drive mappings or file/folder
permissions. Somebody could have messed with them. Next I would relink the
attached tables.

Those are good ideas, thanks, but 1) it's a local installation, so
there should be no drive mappings or file/folder permissions, and 2)
the original mde, which attaches the same tables, is working fine.
Besides, wouldn't that be a 'file or path not found' error, rather than
'you don't have permission...'?

 

[dbahooker]

MDB is crap..

throw it away and rewrite it in access data projects.

spit on anyone that tells you otherwise.

 

[ginnyk]

The first things that I would check are the drive mappings or file/folder
permissions. Somebody could have messed with them. Next I would relink the
attached tables.

Those are good ideas, thanks, but 1) it's a local installation, so
there should be no drive mappings or file/folder permissions, and 2)
the original mde, which attaches the same tables, is working fine.
Besides, wouldn't that be a 'file or path not found' error, rather than
'you don't have permission...'?

 

[ginnyk]

MDB is crap..

throw it away and rewrite it in access data projects.

spit on anyone that tells you otherwise.

Not a very useful suggestion, but thanks for your time

 

[dbahooker]

Access doesn't give the best, most concise information sometimes.

Do you have create permissions in the directory where it lives?
when you open a MDB file it creates a lock file with LDB extension.

-Aaron

 

[Albert D.Kallal]

Do you use a shortcut to specify which workgroup file, or do you have to
'join' a particular workgroup?

If the user changed workgroups, created a new one, or joined a different
one, then that would explain the sudden change.

All normal, and regular mdb/mde files would work, except the one that is
secured.

The above is a good reason why *most* of us when using workgroup security
files ALWAYS setup a shortcut (that way, the user does not have to be joined
to a particular workgroup BEFORE the appcation is launched. And, if the user
joins a different workgroup, then again our short will solve this problem).

So, I would check if the user changed the workgroup file, or perhaps joined
a different workgroup file, or even more likely even created a new group
file. Simply sending them a workgroup file does nothing if you don't have a
shortcut that points to this new workgroup file, or they use the security
menu, and join this workgroup file that you sent them. They might follow
your instructions to place the workgroup file you sent them into the
directory where the "old" workgroup file is..but, that is meaningless if
they joined some other workgroup file on the hard disk....

 

[ginnyk]

The shortcut target is:
"C:\<path>\MSACCESS.EXE" "C:\<path>\cptool.mdb" \User<User> \Pwd<Pwd>
"C:\<path>\cpdata.mdw"
Except for the mdb name, it is the same target used for the cpdata.mde,
that continues to work with no problems (so yes, sending a replacement
mdw was a wasted effort). The tables that are attached to cptool.mdb
are the same tables that are attached to cpdata.mde. I had the client
send me his copy of the tool, so I could check if the permissions had
been changed - they had not. It works as it should on my machines.

I'm beginning to believe this has to be a communication error between
myself and the client, as you suggest. It appears I have covered all
the bases, that there is no mystery reason I hadn't thought of or
didn't know about.

Thank you for your time and effort.

 

[Albert D.Kallal]

The shortcut target is:

"C:\<path>\MSACCESS.EXE" "C:\<path>\cptool.mdb" \User<User> \Pwd<Pwd>
"C:\<path>\cpdata.mdw"

I don't see a wrkgrp switch in the above??

"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE"
"C:\Documents and Settings\All Users\Application Data\Rides\RidesXP.mdb"
/wrkgrp "C:\Documents and Settings\All Users\Application
Data\Rides\Rides.mdw"

note how I used the /wrkgrp switch, and I don't see that in your
example.....

Also, I never used \ (back slash) in place / (forward slash) ....do they
even work??

 

[ginnyk]

My fault. Typos. I'm wearing so many hats, it's beginning to put
pressure on my brain. There IS a /wrkgrp switch, and all the switches
have forward slashes.