Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Fastest implementation? 2

Status
Not open for further replies.

sozzer

Technical User
Apr 4, 2005
73
GB
I'm in the process of building an application that will allow people to record time spent doing tasks on, and then allow us to automatically generate reports against forecast etc.

Basically, about 45 users in different locations are likely to have the db open all day, all of whom will have a common path mapped. Some of the tables in my db are linked from another db also on the server.

Be grateful if someone could please give me some guidance as to the best way to implement this, or whether it really matters! Should I have a front end on each person's computer that links to the back end database, and, if so, should i have the linked tables going from the client db to my BE db to the other source db, or straight from the client db direct to the two BE dbs? Or would i be better just having one file on the server that holds all data and forms etc, that everyone opens? The form that will be open all day on each user's machine is not bound to a recordset - the data's brought in and updated as and when required.

Many thanks
 
By 'must', I mean that it would be a bad idea not to split the database. It is likely to lead to corruption, amonst other things.
 
Very good advice from Remou.

Unbound, rather than bound forms are better in this scenario as they will limit the amount of time users are actually connected to your backend database.

A few other things you may want to consider:

1. You may want to have users entering data into a table in the local frontend and then appending the data to the master backend table on a periodic basis. This will reduce the amount of data being sent across the network.
2. Any reference data that is not frequently updated can be stored in tables in the local frontend.
3. Database replication may be appropriate, but I wouldn't use this until you have trialed the system without replication.

Ed Metcalfe.

Please do not feed the trolls.....
 
Cheers guys! That deserves a couple of stars...
 
You're welcome.

One other thing I forgot to mention - it sounds like you have a good idea of how to design the system already so build it as you hope it will work and then optimise later if required. Don't waste time optimising during the initial development as it may be unrequired.

Good luck and post back if you have any further questions.

Ed Metcalfe.

Please do not feed the trolls.....
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top