Security before Split?

[rhernand]

I found a good place to start security:


http://support.microsoft.com/defaul...kb;en-us;289885

However, since I am going to deploy the application on the network with half the clients having r/w and the other half read only, should I split the mdb first than build the security on the fe, or built the security than split the mdb?

 

[KenHigg]

How do you plan on splitting the db?

 

[rhernand]

Splitting

I use the Database Splitter under Tools/Database Utilities. I am going to house the be(tables) on the network and the fe will be copied to each of the client's workstations with a link to the be.

 

[KenHigg]

Never used the splitter tool. I suspect your bigger problem will be actually implementing security.

I would consider the following:

1. Do a new empty FE and BE db and .mdw with all the basic securty in place.
2. Import objects to the appropriate mdbs

Otherwise, if you try to secure an existing db, you will have to change ownership, permissions, etc. for each object. If you import, and are signed in as administator/dbOwner, the objects should inherit the admin as the new owner.

Hope I am correct on this and that it this makes sense...

 

[rhernand]

Split

I split the mdb because I thought this was the best way to deploy an application on the network for multi-user access. Is there a better way? I am having problems understanding security and may just go with LAN security; create a LAN workgroup with users having r/w access to the folder and with users having read only access to the folder where the be resides.

 

[KenHigg]

I think your on the right track to 'Split' the db. I just never used the split wizard (or whatever it's called). I think both ways just end up with tables in one .mdb and everything else in another .mdb.

Access security is a bear till you get the hang of it.

If you do use network security, you might consider doing a read only version of the front end because you get read / write errors if you just lock down the primary FE.

 

[rhernand]

Deploying

I need to copy the fe to each of the client's pc because the application creates temp tables for the reports. Therefore all client's will have r/w access to the fe. I am not allowing access to the db design by checking off all views in the Startup before deploying. I will keep a copy of the original fe elsewhere for future enhangements of course.

 

[KenHigg]

Cool, Share your progress / problems.

 

[ghudson]

Your users will need to be able to add/edit/delete files within the directory that the front end and back end is located. The record locking [*.ldb] file is created when the first person opens the db, the next users will edit the record locking file if it is already opened and the last user to close the db will delete the record locking file. You [and your users] will have problems accessing and using the db if they do not have the correct permissions to add/edit/delete files within the directory that the db is located.

You will need to use Access security to limit what your users can do in your db.

 

[KenHigg]

Could he put the .ldb in a read write folder on the network?

 

[ghudson]

Access controls the .ldb [record locking] file. Access creates it in the same directory that the database is located in. Access edits it each time a user opens and closes the db and Access deletes the .ldb file when the last user closes the db.

That is why you can not open and edit a db from a CD-ROM and also if the user does not have the needed permissions to the directory that the db is located in.