Users locked out of secure DB

[Steve Kendrot]

I have created a split database and implemented security
on both ends. In the FE, I gave all users in the NUTECREW
group full permissions to tables. On the BE, I gave
NUTECREW read permision on all tables and update,edit,
insert, delete on several tables. The problem is when I
log onto either the FE or the BE, I am denied access and
told to contact DB administrator to assign the appropriate
permissions. So for grins, I assigned full permissions to
all tables for NUTECREW and a user in that group still
cannot open the tables (through forms) in the FE and I
can't even get into the BE when logginG on as a member of
NUTECREW.

Everything works fine when I am logged in as the
administrator, whose permissions are defined by the group
NUTEBOSS. AS LONG AS the tables are linked in the FE using
standard drive mapping. However, if I link the tables in
the FE using UNC, and log in as the administrator/owner, I
can only view the forms as read only.

Can anyone shed any light on my problems?

Thanks

Steve

 

[Joan Wild]

Hi Steve,

I have created a split database and implemented security
on both ends. In the FE, I gave all users in the NUTECREW
group full permissions to tables. On the BE, I gave
NUTECREW read permision on all tables and update,edit,
insert, delete on several tables. The problem is when I
log onto either the FE or the BE, I am denied access and
told to contact DB administrator to assign the appropriate
permissions.

You are being denied access right at login? If so, then the users don't
have Open Permission on the Database Object.

So for grins, I assigned full permissions to
all tables for NUTECREW and a user in that group still
cannot open the tables (through forms) in the FE and I
can't even get into the BE when logginG on as a member of
NUTECREW.

Open Permission on the backend Database Object as well.

 

[Steve Kendrot]

Joan,

Thanks. you were correct. After double ensuring I had
assigned permissions to objects, I never thought to assign
permission to open the database itself. Who'd a thunk it?!

On another note, I found it very cumbersome to get my FE
copied to my workstations. As it turns out, Window's would
not let me copy the database and paste over the network.
Instead I had to create a new database with the same name
on each machine and import all the objects from the
original copy. I did this while logged onto the custom
workgroup I created the original database with. The
permissions and security features did not come with the
imported objects however. Do I need to rerun the security
wizard on every copy? There must be an easier way. Can it
be done without code?

Thanks

Steve

 

[Joan Wild]

Hi Steve,

Joan,

On another note, I found it very cumbersome to get my FE
copied to my workstations. As it turns out, Window's would
not let me copy the database and paste over the network.

This really is the only way. Why can't you copy over the network? If the
workstations have problems with a simple file copy, they will undoubtedly
have trouble connecting with the backend over the network.

Instead I had to create a new database with the same name
on each machine and import all the objects from the
original copy. I did this while logged onto the custom
workgroup I created the original database with. The
permissions and security features did not come with the
imported objects however. Do I need to rerun the security
wizard on every copy? There must be an easier way. Can it
be done without code?

Importing secure objects into a new database will not work. As you found
out the new objects are not secured.

An alternative to copying over the network, would be to copy your secure FE
to CD and copying from the CD on each workstation. If you do this, after
copying to the harddrive, open Windows Explorer, right-click the FE mdb and
remove the read-only check.

However, your best bet is to copy over the network.

 

[Steve Kendrot]

Hi Joan,

I just figured out why I couldn't copy and paste the FE
throught the networks. Share permissions for the
destination folders were set to read only....wish I had
checked that yesterday! Think I will overwrite the files I
created yesterday because I didn't get the security set up
on each version the same so was running into problems on
the different workstations.

I've been reading up on replication. Would you recommend
going this route? I think my plans are to have two
databases. A stripped down version designed for users, and
another designed for analysis of data. Is this a common
practice?

Also, what kind of systems do database managers use to
keep track of queries etc... I find the DB gets confusing
once I start building queries on queries. Many of my
reports are built on tiered queries. I've often thought it
would be convenient if access allowed subfolders in the
database window to organize groups of related queries. Is
there any way of generating a list of queries involved
with creation of a specific report? I often create queries
which I don't wind up using and if I'm not carefull about
deleting them right away, I often forget if they are a
vital component of some report.

I'm a wildlife biologist with no computer background and
stumble my way through this database development. It sure
is nice to have a resource like this forum to turn to.
Without folks like yourself who are so generous with their
time and knowledge, I (and many others from the looks of
it) would really be lost.

Thanks again.

Steve

 

[Joan Wild]

Hi Steve,

I just figured out why I couldn't copy and paste the FE
throught the networks. Share permissions for the
destination folders were set to read only

The destination folders? I assumed you were copying the frontend mdb to
each workstation; that's what you should do.

Split the database into frontend/backend. The backend (tables only) would
sit on your server. A copy of the frontend (linked to the backend) would be
put on each workstation.

Folder permissions must be set to full for the users. i.e. Both the folder
on the server where the backend is, and the folder on the workstation. The
users need to be able to create and delete the associated ldb files.

I've been reading up on replication. Would you recommend
going this route?

No. If all your users are on the same LAN, you don't need to use
replication.

I think my plans are to have two
databases. A stripped down version designed for users, and
another designed for analysis of data. Is this a common
practice?

If you split the database, you can create as many frontends linked to it as
you like.

Also, what kind of systems do database managers use to
keep track of queries etc... I find the DB gets confusing
once I start building queries on queries. Many of my
reports are built on tiered queries. I've often thought it
would be convenient if access allowed subfolders in the
database window to organize groups of related queries.

I haven't used the feature, but in Access 2002 (can't remember if 2000 has
this), you can create Groups in the database window; and then right-click an
object 'Add to Group'. Also you don't have to use saved queries as record
sources for forms/reports. You can use SQL statements - that might cut down
on the number of queries. As for keeping track, you can use Total Access
Analyzer from www.fmsinc.com to document *everything*. It's quite
extensive.

Is
there any way of generating a list of queries involved
with creation of a specific report? I often create queries
which I don't wind up using and if I'm not carefull about
deleting them right away, I often forget if they are a
vital component of some report.

TAA would help with this as well. A cheap, but time-consuming method is to
rename a suspect query to zname. Test your reports and see if you get any
errors.

I'm a wildlife biologist with no computer background and
stumble my way through this database development. It sure
is nice to have a resource like this forum to turn to.
Without folks like yourself who are so generous with their
time and knowledge, I (and many others from the looks of
it) would really be lost.

I used to be a forester and I stumbled in Access at first, too. I learned a
lot from newsgroups, so I'm here to give back a little (and I like helping
people).

Good luck!