Can't get exclusive access to BE DB if a FE DB is open.

[khughes46]

I have a master DB (BE) with all the tables I need for other FE DB applications. The FE DB's are linked to the tables in the BE DB. There 4 applications with their own DB linking back to the BE DB. The BE DB has Queries, Forms and Macros that are used exclusively in the BE and are not linked anywhere. Each FE DB's is linked to only the tables required for its specific application. Some tables are used in more than one application DB. All of the DB's are in shared folders. I thought that this type of split and setup would give me access to the BE DB regardless of the status of any FE DB. What am I missing?

[JoeM]

Since all the FE DBs are linked to the BE DBs, anytime anyone is in any of the databases, the BE will be locked. You need to get everyone out to get exclusive access.

BTW, you should not have Queries, Forms, and Macros in your BE DB. If you have different tasks that you want to do that you do not want to give to others, simply create a different FE DB (you can have multiple FE versions all connecting to the same BE). That way you will be able to easily update/edit that FE without having to kick everyone out of your BE. Your BE really should just be a data repository, nothing more.

[khughes46]

Didn't fully realize that about only data in the BE, thanks for the tip. However, sometimes I have to make table changes or add new tables, so I guess I have to wait for all users to be out of their connecting DB's. But that should be OK since I only make those changes after hours when everybody should be out. Unfortunately some of my users haven't gotten used too the idea of exiting the DB when finished or before they go home.

[JoeM]

If it is only data tables in your back-end, then the only time you need to get everyone out is when you make changes to the tables. There is no getting around that part. But if you have removed all other objects (Queries, Forms, Reports, Macros), then at least you do not need to kick them all out to make changes to those things.

Regarding your users who don't logout, I have seen some articles on automatically kicking users out after a period of time. A simple Google Search returned this:
http://www.accessmvp.com/JConrad/acc...e/kickoff.html
http://www.databasejournal.com/featu...aintenance.htm

[khughes46]

Thanks for the links. The second one looks very promising.

[June7]

I am able to make changes to BE when users are accessing, as long as I am not trying to change a table that is being utilized at that moment. Right now I am adding a new table.

[JoeM]

I am able to make changes to BE when users are accessing, as long as I am not trying to change a table that is being utilized at that moment. Right now I am adding a new table.

Good to know that is possible. Of course, that can always be tricky, as if users are in the database doing stuff, who knows when they will try to access stuff in the other tables on you. I find it is just easier/safer to boot them all out when trying to make changes to back-end tables.

[June7]

Agree, that is safest. But we are a small group. I can usually time my edit for when I am sure no one will be using table I want to edit. And adding a new table has never been an issue.

[JoeM]

And adding a new table has never been an issue.

Good point. That would not be an issue since the any new table obviously wouldn't have been mapped to the FE yet, so there is no danger of any issue there.

I can usually time my edit for when I am sure no one will be using table I want to edit.

I'm jealous! What's it like to have predictable users?

[khughes46]

Since my DB's are small, I think I want to create stand-alone mirror images of the FE DB's and use them to make changes, then import into the live DB's. his will let me work on forms and reports as needed. Sometimes reports need to be changed on the fly.

[JoeM]

Since my DB's are small, I think I want to create stand-alone mirror images of the FE DB's and use them to make changes, then import into the live DB's. his will let me work on forms and reports as needed. Sometimes reports need to be changed on the fly.

What I typically do is instead of putting a shortcut to the FE DB on my user's Desktops, I give them a shortcut to a batch file I have on the network. What the batch file does is get a fresh copy of the FE DB from the network and copy it to their hard-drive, and then opens that copy on their computer.

That allows me to easily make changes to the front-end and distribute it automatically without having to do anything special (I simply replace the FE copy on the network that is being copied down by the batch file).

[June7]

I used to use a batch file to copy the FE then discovered code within the db itself can accomplish. Review https://www.accessforums.net/code-re...end-33331.html