Secured Database works exactly right on one computer, but on another not quite r

[JessicaMorris]

I set up user-level security on an Access 2003 DB on a Windows XP machine,
using the security wizard. I'm almost positive that I tested it and it
worked correctly at the very beginning.

However, at midnight before a presentation the next morning, I was unable to
edit the data. I already looked at lots of discussions, and don't find
anything quite like my problem. I'm fairly sure it's set up properly, after
having read several threads and looked at the FAQ and also a better link to
jmwild, since the FAQ isn't current for 2003. I have set up a similar one
previously, except that the 'master' was actually the primary user's machine,
and it worked perfectly from the first moment.

On my machine, I am prompted for user id/password, and only those set up are
allowed. Some users are read only and some are full data. I have a FE/BE
set of DB's. The 'master' FE, BE, and mdw file are on my Windows XP
(completely current) machine. Only I have access to the objects, which is
correct, but no one, not even me or ADMIN can edit or add data. All the
other users can log on fine, but not edit data.

In desperation, I copied the FE to my second Windows 2000/Office 2003 machine,
from which I was planning to demo anyway, and it works perfectly there! The
first few times I copied the 'master' to the second machine, I held my breath,
afraid that it would not work, but it always does. It really looks like it's
the MACHINE, not the setup, but I just don't see how that could be.

I've tried executing the 'good' copy across the network from my machine...no
good! However, if I connect remotely to that machine and actually execute it
on that machine from mine, it works perfectly. But it's a pain in the neck
to have to connect remotely to the other machine, to test forms, etc. or just
making minor edits.

My shortcut on the second machine is "C:\Program Files\Microsoft Office 2000\
OFFICE11\MSACCESS.EXE" "C:\MAMG\MasterGardeners.mdb" /WRKGRP "M:\Security.
mdw". M: is mapped to the folder on my machine. The data is linked to the
BE on my machine. I realized in researching this problem that I also need to
join the BE to the workgroup, but I'm waiting until I get this resolved.
(Yes...I know the path to Access says Office 2000, rather than 2003, but it
was upgraded and the existing office folder was Office2000; I didn't want to
tinker with changing the folder name. It is 2003.)

Can anyone help?

Thanks,
Jessica

 

[Rick Brandt]

I set up user-level security on an Access 2003 DB on a Windows XP
machine, using the security wizard. I'm almost positive that I
tested it and it worked correctly at the very beginning.

However, at midnight before a presentation the next morning, I was
unable to edit the data. I already looked at lots of discussions,
and don't find anything quite like my problem. I'm fairly sure it's
set up properly, after having read several threads and looked at the
FAQ and also a better link to jmwild, since the FAQ isn't current for
2003. I have set up a similar one previously, except that the
'master' was actually the primary user's machine, and it worked
perfectly from the first moment.

On my machine, I am prompted for user id/password, and only those set
up are allowed. Some users are read only and some are full data. I
have a FE/BE set of DB's. The 'master' FE, BE, and mdw file are on
my Windows XP (completely current) machine. Only I have access to
the objects, which is correct, but no one, not even me or ADMIN can
edit or add data. All the other users can log on fine, but not edit
data.

In desperation, I copied the FE to my second Windows 2000/Office 2003
machine, from which I was planning to demo anyway, and it works
perfectly there! The first few times I copied the 'master' to the
second machine, I held my breath, afraid that it would not work, but
it always does. It really looks like it's the MACHINE, not the
setup, but I just don't see how that could be.

I've tried executing the 'good' copy across the network from my
machine...no good! However, if I connect remotely to that machine
and actually execute it on that machine from mine, it works
perfectly. But it's a pain in the neck to have to connect remotely
to the other machine, to test forms, etc. or just making minor edits.

My shortcut on the second machine is "C:\Program Files\Microsoft
Office 2000\ OFFICE11\MSACCESS.EXE" "C:\MAMG\MasterGardeners.mdb"
/WRKGRP "M:\Security. mdw". M: is mapped to the folder on my
machine. The data is linked to the BE on my machine. I realized in
researching this problem that I also need to join the BE to the
workgroup, but I'm waiting until I get this resolved. (Yes...I know
the path to Access says Office 2000, rather than 2003, but it was
upgraded and the existing office folder was Office2000; I didn't want
to tinker with changing the folder name. It is 2003.)

Can anyone help?

Thanks,
Jessica

What permissions did you grant users to the FOLDER where the file resides?
They need pretty much full permissions (file create, file execute, file
edit, file delete) or else Access cannot properly manage the locking file
(LDB) that allows multi-user locking to be controlled. If that file is not
created then edits are not allowed.

The reason that would affect you is once one person without file create
enters the app then everyone after that will also be read only because only
the first person to open the file can cause the LDB file to be created. If
you were the first person to open the file I would expect you to be able to
edit records.

 

[JessicaMorris via AccessMonster.com]

I set up user-level security on an Access 2003 DB on a Windows XP
machine, using the security wizard. I'm almost positive that I

[quoted text clipped - 44 lines]

Thanks,
Jessica

What permissions did you grant users to the FOLDER where the file resides?

**Modify (I've been using this DB for > 1 year in this location before I
enabled user security.)

They need pretty much full permissions (file create, file execute, file
edit, file delete) or else Access cannot properly manage the locking file
(LDB) that allows multi-user locking to be controlled. If that file is not
created then edits are not allowed.

*****It's there...I haven't enabled security on the BE yet, because of this
problem. I can open it and edit the data just fine.

The reason that would affect you is once one person without file create
enters the app then everyone after that will also be read only because only
the first person to open the file can cause the LDB file to be created. If
you were the first person to open the file I would expect you to be able to
edit records.
*****Me too...

Thanks,

 

[Joan Wild]

I set up user-level security on an Access 2003 DB on a Windows XP
machine, using the security wizard. I'm almost positive that I
tested it and it worked correctly at the very beginning.

On my machine, I am prompted for user id/password, and only those set
up are allowed. Some users are read only and some are full data. I
have a FE/BE set of DB's. The 'master' FE, BE, and mdw file are on
my Windows XP (completely current) machine. Only I have access to
the objects, which is correct, but no one, not even me or ADMIN can
edit or add data. All the other users can log on fine, but not edit
data.

It sounds as though you tinkered with permissions after running the wizard
(or perhaps ran the wizard a second time?). You say your username has
access to the objects, but you can't edit/add data. What do you mean by
access? What permissions does the full data group have on the data sources
of your forms? You can check this in Tools, security, permissions.

In desperation, I copied the FE to my second Windows 2000/Office 2003
machine, from which I was planning to demo anyway, and it works
perfectly there! The first few times I copied the 'master' to the
second machine, I held my breath, afraid that it would not work, but
it always does. It really looks like it's the MACHINE, not the
setup, but I just don't see how that could be.

Sounds like you might be using a different mdw file on the problem machine.

My shortcut on the second machine is "C:\Program Files\Microsoft
Office 2000\ OFFICE11\MSACCESS.EXE" "C:\MAMG\MasterGardeners.mdb"
/WRKGRP "M:\Security. mdw". M: is mapped to the folder on my
machine.

Try using UNC pathname for the security.mdw.
\\machinename\path\security.mdw You have some extra spaces in your shortcut
that shouldn't be there like 2000\spOFFICE11 and alos Security.spmdw

The data is linked to the BE on my machine. I realized in
researching this problem that I also need to join the BE to the
workgroup, but I'm waiting until I get this resolved.

In that case, the problem is with the permissions in the FE or the wrong
shortcut or wrong mdw for the FE. Since the BE is secured, anyone with any
mdw can read the data.

 

[Chris Mills]

It's nothing to do with "security setup and permissions".

She says it works fine on some PC's and not others. If it runs fine on some
PC's, then it is by-and-large set up correctly.

She obviously has different mdw's being implemented on different machines.
Even though they may be the same name and she thinks they're the same. That's
my call...
....because, she is happy with some machines and not others. That's a
difference in the files the machines are accessing, and nothing otherwise to
do with the complications of setting up Access Security.

(I cant tell from here whether it's a different mdb, mdw, shortcut, or
permissions on a folder, but it strikes me as one of those, rather than
whether she has "set up security correctly". It is up to her to establish the
precise difference between machines, which could be any of the above but NOT
basic security setup)

She all but SAYS it's a difference of different files on different machines
(well, as I see it, 50% chance of being wrong as usual!)
Chris

 

[JessicaMorris via AccessMonster.com]

I set up user-level security on an Access 2003 DB on a Windows XP
machine, using the security wizard. I'm almost positive that I

[quoted text clipped - 7 lines]

edit or add data. All the other users can log on fine, but not edit
data.

It sounds as though you tinkered with permissions after running the wizard
(or perhaps ran the wizard a second time?).

I assume you're talking permissions in the security...no, I didn't.

You say your username has

access to the objects, but you can't edit/add data. What do you mean by
access?

I can create, delete, and edit forms, queries, reports, macros, etc....
everything except data. The other users can't, which is as it should be.
Even the admin account can't edit data.

What permissions does the full data group have on the data sources

of your forms?

You can check this in Tools, security, permissions.
Read design, Read data, Update data, Delete data, on both machines
I have looked at Security on both machines and it appears to be identical...
the SAME FILE.

Sounds like you might be using a different mdw file on the problem machine.

I don't see how that is possible. I only created one security file. When I
look at security from either machine, I see all the users and the permissions
look to be identical. Yesterday, I added a user, and I see him from the
security menu on both machines.

Both shortcuts point to the same security file.

On my machine, the shortcut is:
"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" "C:\Documents and
Settings\Jessica\My Documents\MasterGardeners\DataBase\MasterGardeners.mdb"
/wrkgrp "C:\Documents and Settings\Jessica\My Documents\MasterGardeners\
DataBase\Security.mdw"

On the other:
"C:\Program Files\Microsoft Office 2000\OFFICE11\MSACCESS.EXE" "C:\MAMG\
MasterGardeners.mdb" /WRKGRP "M:\Security.mdw"
M: is mapped to "C:\Documents and Settings\Jessica\My Documents\
MasterGardeners\DataBase" on my machine.

Try using UNC pathname for the security.mdw.
\\machinename\path\security.mdw

It's the remote machine that works properly, using the reference to M:. On
my machine everything is in the same folder in My Documents... no reason to
use UNC there.

You have some extra spaces in your shortcut
that shouldn't be there like 2000\spOFFICE11 and alos Security.spmdw

There is actually a space in the folder name for Access (there are quotes);
not sure why there appears to be a space in the mdw in the post; it is not
there.......I copied/pasted then just like I did above just now.

In that case, the problem is with the permissions in the FE or the wrong
shortcut or wrong mdw for the FE. Since the BE is secured, anyone with any
mdw can read the data.

I agree with you about where it appears the problem is....but I am copying
the FE from my machine to the other one, and referencing the same mdw. I
don't see any possibility that both machines are not using the same security.
mdw. I did a search on my entire C: drive for *.mdw, and found only this one,
two other ones with completely different names that I use (successfully) for
other DB's. Actually, I was expecting to see the default system.mdw that
everything I read said not to use, but didn't find it.

What it looks like to me is that it's related to the MACHINE, although I
don't see how that could be...

I understand that the BE is exposed. I'm going to join it to the same
security as soon as I get this resolved. Right now, editing the BE directly
is the only way I can edit the data on my machine.

 

[JessicaMorris via AccessMonster.com]

It's nothing to do with "security setup and permissions".

She says it works fine on some PC's and not others. If it runs fine on some
PC's, then it is by-and-large set up correctly.

She obviously has different mdw's being implemented on different machines.
Even though they may be the same name and she thinks they're the same. That's
my call...

***I searched both machines for *.mdw....found only those for two other DB's
that I have security on and am using successfully on both machines, and on
the second machine...the one that works correctly, I found several system.mdw.
But if I try just opening the DB directly on the remote machine, without the
shortcut with the correct mdw, I get the message, "you don't have permission",
so I'm not defaulting to another mdw.

When I look at the users, I see exactly the same users on both machines. And
I added a user yesterday from my machine, and I see him on both machines. I
just don't think it's possible that both implementations aren't using the
same mdw.

I know this doesn't make any sense....

I have had this exact same implementation running successfully for several
years on ~ 15 computers at 2 other locations.....one BE, one mdw on a 'master
machine', and FE referencing them on all the others. I understand how it
needs to be set up. I just don't see how this is any different from that one,
and everything I found in other posts seems to be right. Still, it's not
working...

...because, she is happy with some machines and not others. That's a
difference in the files the machines are accessing, and nothing otherwise to
do with the complications of setting up Access Security.

(I cant tell from here whether it's a different mdb, mdw, shortcut, or
permissions on a folder, but it strikes me as one of those, rather than
whether she has "set up security correctly". It is up to her to establish the
precise difference between machines, which could be any of the above but NOT
basic security setup)

***I'm copying this mdb to the other machine. I'm referencing the ONLY copy
of Security.mdw on my network. The shortcut uses the COPIED mdb and the ONLY
mdw. I was using this DB for > 1 year successfully before implementing
security, so I don't see how it could be folder permissions...and it's in My
Documents, so that wouldn't be a problem.

Actually, if anything, the other machine is where I might expect problems...
it's an old machine, that has at one time had Access 95, 97, and 2000 on it
at the same time, and 2000 was upgraded to 2003. I know all the advice is
not to do that, but I was supporting DB's in all those versions, and it was a
bear to get set up initially. But I never had anything other than minor
annoyances with the multiple versions. But that is the machine that works!
The one I'm having problems with is relatively new, original installation of
XP, only ever had Office 2003....no glitches that I'm aware of.

She all but SAYS it's a difference of different files on different machines

***That's not what I intended to say...:>) That's the one thing I was
pretty sure was right from the beginning, because I've set up the same thing
at two other locations previously. I was hoping it would be something I had
done inadvertantly in the security that I'm not recognizing.

What it looks like to me is SOME difference between the machines, but the
setup seems to be right. And remember, I started out on my machine...the one
that doesn't work. What you'd expect to have trouble with is the remote
machine....

 

[JessicaMorris via AccessMonster.com]

I set up user-level security on an Access 2003 DB on a Windows XP machine,
using the security wizard. I'm almost positive that I tested it and it
worked correctly at the very beginning.

However, at midnight before a presentation the next morning, I was unable to
edit the data. I already looked at lots of discussions, and don't find
anything quite like my problem. I'm fairly sure it's set up properly, after
having read several threads and looked at the FAQ and also a better link to
jmwild, since the FAQ isn't current for 2003. I have set up a similar one
previously, except that the 'master' was actually the primary user's machine,
and it worked perfectly from the first moment.

On my machine, I am prompted for user id/password, and only those set up are
allowed. Some users are read only and some are full data. I have a FE/BE
set of DB's. The 'master' FE, BE, and mdw file are on my Windows XP
(completely current) machine. Only I have access to the objects, which is
correct, but no one, not even me or ADMIN can edit or add data. All the
other users can log on fine, but not edit data.

In desperation, I copied the FE to my second Windows 2000/Office 2003 machine,
from which I was planning to demo anyway, and it works perfectly there! The
first few times I copied the 'master' to the second machine, I held my breath,
afraid that it would not work, but it always does. It really looks like it's
the MACHINE, not the setup, but I just don't see how that could be.

I've tried executing the 'good' copy across the network from my machine...no
good! However, if I connect remotely to that machine and actually execute it
on that machine from mine, it works perfectly. But it's a pain in the neck
to have to connect remotely to the other machine, to test forms, etc. or just
making minor edits.

My shortcut on the second machine is "C:\Program Files\Microsoft Office 2000\
OFFICE11\MSACCESS.EXE" "C:\MAMG\MasterGardeners.mdb" /WRKGRP "M:\Security.
mdw". M: is mapped to the folder on my machine. The data is linked to the
BE on my machine. I realized in researching this problem that I also need to
join the BE to the workgroup, but I'm waiting until I get this resolved.
(Yes...I know the path to Access says Office 2000, rather than 2003, but it
was upgraded and the existing office folder was Office2000; I didn't want to
tinker with changing the folder name. It is 2003.)

Can anyone help?

Thanks,
Jessica

***not sure if this is how to post additional info, without actually
responding to someone else...

Just for fun, I copied an unsecured DB to a test folder on the machine I'm
having trouble with...and joined it to the mdw I'm using on the secured DB
I'm having trouble with. IT WORKS PERFECTLY! A different DB...same mdw.

Now I'm really blown away! How can this be?

HELP!!!

Thanks,
JMM

 

[Joan Wild]

On the problem machine, what happens if you use the workgroup administrator
to join your secure mdw by default and then open the secure mdb - does it
work then?

 

[Joan Wild]

It's nothing to do with "security setup and permissions".

I see. I'll leave it to you to solve the mystery then.

 

[JessicaMorris via AccessMonster.com]

Same thing...recordset not updatable, new record gray....

On the problem machine, what happens if you use the workgroup administrator
to join your secure mdw by default and then open the secure mdb - does it
work then?
[quoted text clipped - 62 lines]

 

[Joan Wild]

Well that is not a security issue. You could get that message with an
unsecured mdb as well.

Is this a form or query that you are opening?

In either case (the form's recordsource, or the query) is not updateable.
If you search in Help for updateable query you will get a list of cases when
a query can't be updated.


--
Joan Wild
Microsoft Access MVP

Same thing...recordset not updatable, new record gray....

On the problem machine, what happens if you use the workgroup
administrator to join your secure mdw by default and then open the
secure mdb - does it work then?

I set up user-level security on an Access 2003 DB on a Windows XP
machine, using the security wizard. I'm almost positive that I

[quoted text clipped - 62 lines]

 

[JessicaMorris via AccessMonster.com]

I'm going to start over....unsecure the DB, add security. I'm SURE that it
worked when I first set it up. Something happened along the way...I'll let
you know.

Thanks for your help!

Well that is not a security issue. You could get that message with an
unsecured mdb as well.

Is this a form or query that you are opening?

In either case (the form's recordsource, or the query) is not updateable.
If you search in Help for updateable query you will get a list of cases when
a query can't be updated.

Same thing...recordset not updatable, new record gray....

[quoted text clipped - 11 lines]

Message posted via AccessMonster.com

 

[Chris Mills]

I see. I'll leave it to you to solve the mystery then.

The importance of Joan in not welcoming other opinions is the only thing which
is suspect here!

What a pathetic and undeserving response, Joan. You can do better. As far as I
can tell, the issue was unresolved or the error descriptions were inaccurate.
I expect better than plain bitchiness from the likes of you.

Regards, Chris

 

['69 Camaro]

Hi, Chris.

What a pathetic and undeserving response, Joan. You can do better. As far
as I
can tell, the issue was unresolved or the error descriptions were
inaccurate.
I expect better than plain bitchiness from the likes of you.

Geez! Someone got up on the wrong side of the bed!

Regards, Chris

This closing does not comport with such salient remarks. "Regards" implies
a feeling of respect and affection, or of someone held in high esteem. May
I instead suggest "Bitterly, Chris" as a closing for your future retorts?

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blog: http://DataDevilDog.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[Chris Mills]

"Regards" implies a feeling of respect and affection...

Then you have an inability to differentiate one of her posts from her
majority.

(In this case, clearly stiffling other suggestions)

Cheerfully
Chris

 

['69 Camaro]

Hi, Chris.

Where I come from, anyone who utters such disrespectful words to a colleague
as you have, publicly or privately, even once, would quickly find dents in
his resume and a new job in Antarctica, no matter how loudly or how often he
claims to have respect for that colleague 99.99% of the time.

Reflectively,
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blog: http://DataDevilDog.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[Chris Mills]

And yet you pig-headedly deny her "bitchy" comment, which was devoid of any
technical merit.

For the record, I have worked for a year in Antarctica, so that was a bad
example.

So have many military at the nearby McMurdo Station. You are running
dangerously close to a recent US politician gaff who said "If you don't work
hard you may end up Stuck in Iraq". (Bush merely compounded the innuendo in a
subsequent statement, some Commander-in-Chief!)

Antarctica was a bad example, whatever point it was you wished to make beyond
an inability to read her message. Her disrespect engenders disrespect, and
then we wonder where it all started.

Regards (meaning I think you often have very valuable technical expertise)
Chris

PS for the record, you could argue that I should have put "Otherwise Regards".
Also for the record, take the trouble to analyse her non-technical statement
with a degree of independence. I have no idea why she said such a thing.

You have made your point, as I have. I should not have responded to a bitch
with a bitch (the verb)

Reflectively,

Well then, don't stand in front of a loose cannon <g>