MS Access Should I split my database?
I created a database that manages tasks/projects with report and query features.
The database will held on a network share with a max of 4 employee's connected at a given time.
Should I split it?
Any other advice to enhance integrity and avoid corruption?
The database will held on a network share with a max of 4 employee's connected at a given time.
Should I split it?
Any other advice to enhance integrity and avoid corruption?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
To be sure,
Splitting the database (for evenr *1* user) will always be a good idea.
See here too:
http://www.techrepublic.com/blog/10things/10-reasons-to-split-an-access-database/1119
And to be totally fair, ...yes , ...you can run an UNsplit DB if the number of users is low and the number of users in the DB at any one time will also be low (concurrency)...
*However* there will always exist the possibility of a crash that would not happen if the db was split.
When you Share one Access db file (for lack of a simpler explanation here), the user must pull down the entire app over the network.
This means that another use logging in may not have access to the db if something is open in design view.
It also means that you open yourself up to any number of the "Conflict" errors in Access.
But back to the "crash" scenario, with one user pulling the DB over the network.
Let's say another user logs into the database and is working.
Everything is fine, and neither user has any problems...
Sound great right...?
Sure, until one users machine goes wonky (crashes, Network hiccup, app lock up, Reboot while DB is open, unexpected "terminal" error, ...etc)
Now you have one machine where the DB is "Crashed", and the other where the db "appears" to be working fine.
Well, with one DB file being "shared", it won't be long before the "Good" database starts showing signs of corruption or worse...
Trust me, this all happened to me...
:-(
JeffCoachman
Splitting the database (for evenr *1* user) will always be a good idea.
See here too:
http://www.techrepublic.com/blog/10things/10-reasons-to-split-an-access-database/1119
And to be totally fair, ...yes , ...you can run an UNsplit DB if the number of users is low and the number of users in the DB at any one time will also be low (concurrency)...
*However* there will always exist the possibility of a crash that would not happen if the db was split.
When you Share one Access db file (for lack of a simpler explanation here), the user must pull down the entire app over the network.
This means that another use logging in may not have access to the db if something is open in design view.
It also means that you open yourself up to any number of the "Conflict" errors in Access.
But back to the "crash" scenario, with one user pulling the DB over the network.
Let's say another user logs into the database and is working.
Everything is fine, and neither user has any problems...
Sound great right...?
Sure, until one users machine goes wonky (crashes, Network hiccup, app lock up, Reboot while DB is open, unexpected "terminal" error, ...etc)
Now you have one machine where the DB is "Crashed", and the other where the db "appears" to be working fine.
Well, with one DB file being "shared", it won't be long before the "Good" database starts showing signs of corruption or worse...
Trust me, this all happened to me...
:-(
JeffCoachman
And to be fair here,...
I have posted a lot of info above.
But the bottom line is that mbizups post is the answer here.
"Split the database"
So I do not want any points,...
(honest)
My info was just an illustration of what might happen if you don't split the db.
I have posted a lot of info above.
But the bottom line is that mbizups post is the answer here.
"Split the database"
So I do not want any points,...
(honest)
My info was just an illustration of what might happen if you don't split the db.
ASKER
Thanks!
Getting the ax out now.
Getting the ax out now.
Jim.