Database Splitting - Some Information Required.

[Robbyp2001]

Hello Folks,
It is clear to me now that the way forward for my database is to split it. Thanks for all the information I have gleaned from here. I have a couple of questions though.
1. If each workstation has to have its own copy of the Front End, where is this stored? Is it held locally on the PC hard drive or is each copy stored in a separate area of the network system and assigned to the individual user?
2. If any future Front End changes are made, does this mean that a new copy of the Front End must be given to each user individually?
3. Does that mean that each time this happens all copies have to be linked again to the Back End database?
My database has approximately 50 users, so I am trying to estimate the downtime involved by issuing a Front End copy and creating the links to the Back End tables.
One other quick question, if I may. I noticed recently that one user had made a copy of the database and was using it locally (don’t know why). If someone was to do the same with a Front End database, would this break the links to the tables, this rendering that copy unusable?

Rob

 

[Robbyp2001]

Wonderful Pat. All my questions answered. You're a star!

Rob

 

[gemma-the-husky]

your points 2 and 3 are generally resolved by some automatic system.

eg. have something in the front end that denotes the version number of front end. have somethingin the back end that denotes the required version number. check the version numbers on startup, and if the version is wrong, inform the user, and exit gracefully

the user can update his local copy by downloading the master copy you provide somewhere on a network drive

your front end can include code to check that the back end is correctly connected, and reconnect if necessary.

the hardest bit is possibly automatically providing the users with an update script, and a desktop shortcut to the database - without actually visiting their machine, but I expect that is doable also

 

[Robbyp2001]

Thanks for your advice Gemma. A bit complicated I think, but I'll certanly look into it. An automated system would be fantastic if it could be done, however manually updating EACH pc over a weekend day is achievable. I reallly don't imagine that the FE fuctionality for ordinary users will change much over the year, only one or two administrators perhaps. It occured to me that splitting the database and issuing FEs would also be an effective method of limiting access to areas of the system thus negating the need for user level passwords. In other words, two or three different FEs could be given out depending on the level of access required by each.

Thank you

 

[jdraw]

There are some automated FE Updater tools out there.

See http://autofeupdater.com/

Tony Toews has/and is active in various forums and groups

Bob Larson has FE and BE tools on his site.
http://www.btabdevelopment.com/ts/freetools

Bob is a moderator on this AWF site.

 

[gemma-the-husky]

Thanks for your advice Gemma. A bit complicated I think, but I'll certanly look into it. An automated system would be fantastic if it could be done, however manually updating EACH pc over a weekend day is achievable. I reallly don't imagine that the FE fuctionality for ordinary users will change much over the year, only one or two administrators perhaps. It occured to me that splitting the database and issuing FEs would also be an effective method of limiting access to areas of the system thus negating the need for user level passwords. In other words, two or three different FEs could be given out depending on the level of access required by each.

Thank you

of course. maintaining 3 different databases for each change is a bind. Probably easier to have a single copy, and put code in to test the user's name etc, before allowing access to certain features.

you will prbably find lots of reasons to make changes - from changes to fix bugs, to adding new functionality, which generally happens when you provide a well constructed dbs