Frontend of Split DB on network or user PC?

[Chaz]

As per the topic .....

When a DB is split, is it best to use a front end on the network or should each user have their own frontend?

Info on splitting databases say that a split system allows for development on the frontend but this is not possible if someone else is using the frontend on a network or have I missed something?

The bad part of having a user version means that each time I make a change, I need to send the users the new version?

Might this fix my multiple user 'locked out' problem?

Thanks

 

[Kafrin]

As per the topic .....
Info on splitting databases say that a split system allows for development on the frontend but this is not possible if someone else is using the frontend on a network or have I missed something?

You are correct that, unless you're working in Access 97 or earlier, you cannot develop the front end while other people are using it.

Incidentally, queries can still be created and changed with other people in the front end.

 

[DCrake]

By placing the front end on the server is like going to a football match everyone is going into the ground through the same turnstile. Things can get crowded. By giving each user their own copy means that everybody has their own private entrance. Nobdy will be blocking their way. Alas this does mean that new versions need to be deployed out to all users, but there are examples on this forum on how to automate this. Using the former is a fire sure way of getting corruption either in the front end or more seriously in the back end data.

David

 

[Chaz]

Thanks, worries me about corruption and current issue that I have with people being locked out. I see the local copy as a means to perhaps sort / fix this.

 

[Galaxiom]

Somewhere recently I saw a post here about a free tool designed to automatically manage the FE distribution. I have the link at work but I expect someone else can point it out before I get back there.

 

[WIS]

As per the topic .....

When a DB is split, is it best to use a front end on the network or should each user have their own frontend?

Info on splitting databases say that a split system allows for development on the frontend but this is not possible if someone else is using the frontend on a network or have I missed something?

The bad part of having a user version means that each time I make a change, I need to send the users the new version?

Might this fix my multiple user 'locked out' problem?

Thanks

With a split db, put the be on the server and the fe on the client PC's. Hint: Put the fe on the server, link to the be and then copy the fe to all client PC's.

If you need to change the fe, have a vs on a PC which can be updated, then copy that to all PC's as before. I never develop the fe using the "real" be but usually off-site with a copy of the be.

Locked out problem: Go to Tools-> Options-> Advanced. Select "Shared" and "Edited Record" and tick "Open db using record level locking".

There are some programs on this site to help in the above, but all I use is a routine to delete all previous links and then relink manually as in my 1st pt above. If you only have a few PC's then this is not as great a problem as it appears.

 

[Chaz]

With a split db, put the be on the server and the fe on the client PC's. Hint: Put the fe on the server, link to the be and then copy the fe to all client PC's.

If you need to change the fe, have a vs on a PC which can be updated, then copy that to all PC's as before. I never develop the fe using the "real" be but usually off-site with a copy of the be.

Locked out problem: Go to Tools-> Options-> Advanced. Select "Shared" and "Edited Record" and tick "Open db using record level locking".

There are some programs on this site to help in the above, but all I use is a routine to delete all previous links and then relink manually as in my 1st pt above. If you only have a few PC's then this is not as great a problem as it appears.

Thanks for the info.

The lockout problem still occurs even with that set on all user's access options. That said, I need to check again as I have been experimenting with changes.

 

[gemma-the-husky]

multiple users in a database (ie shared front end) is a NONO

eg one reason NOT to share a front end

if you make (or use) local tables within the database for ANY reason then users may interfere with one another - modifying the local tables

if each user has their own copy, this won't happen!

 

[Atomic Shrimp]

if you make (or use) local tables within the database for ANY reason then users may interfere with one another - modifying the local tables

if each user has their own copy, this won't happen!

That's the problem that sprang immediately to my mind - if there is a temporary table for (say) entry of an order before submission, it's much easier to be able to wipe that table and reuse it when it's local to the individual user.

It is still possible to do it with multiple users in the same table (just by including a field to store their UserID and making sure they only ever interact with their own records, but that's another potential point of failure, and for the other reasons stated above, I agree, one front end per client is best.

In my particular case, my clients have one front end each, but it's still on the network, because the corporate desktop setup is such that all of the users' documents are stored directly in their home folder on the server (it would be possible to install the front end on their C drive, but running it would require modification of their privileges, etc).

 

[DCrake]

Syncing between home folders on pc and server is fine for ordinary files but it cannot hanlde mdb files as these can change internally. allways have the front end in a specified folder locally, such as C:\Program Files\Applications\AppName\Application.mdb

Then at least the update app knows where the target location should be.

David

 

[Max D]

You can use a launching .bat file for front-end distribution

@copy \\server\lala\database.adp "%TEMP%" /y >nul
@start %TEMP%\database.adp

There is one downside - front-end gets overwritten every time user opens it.

 

[SOS]

As an alternative, there's a free tool that enables "auto updating" of your frontend here on MVP Bob Larson's website.

 

[Joe8915]

Somewhere recently I saw a post here about a free tool designed to automatically manage the FE distribution. I have the link at work but I expect someone else can point it out before I get back there.

That was Bob Larsons sample. Do the search on split database and you will

Access_Front-End_AutoUpdating_Utility. I am in the process of doing one.

Doing the test, test, test and read, read, read.