Multi user application and precaution
- Thread starter DevAccess
- Start date
- Local time
- Today, 18:15
- Joined
- Feb 19, 2013
- Messages
- 17,564
depends what level you want to take it. Main requirement is all data is in backend database located somewhere convenient on the network and all forms/reports/queries/code/macros are in a front end db (with linked tables to back end) located on each users machine.
Ideally user front end will be .accde (so they cannot mess with code etc) with navigation and ribbons hidden and bypass keys disabled - although easily got round by a half way experienced access user. Each user will need their own implementation of access, or you provide the free access runtime.
Ideally user front end will be .accde (so they cannot mess with code etc) with navigation and ribbons hidden and bypass keys disabled - although easily got round by a half way experienced access user. Each user will need their own implementation of access, or you provide the free access runtime.
And I would definitely take enough time to properly test your Frontend / Backup setup.
I have been running a non-split database quite successfully for years, but after reading everyone's advice I decided to split my Database. It became very slow and just unable to work with.
I believe there are many small parameters and settings that you can change to improve things, but up to now we are still working the non-split way.
So take your time to properly test the Frontend / Backend setup with multiple users being logged in at the same time.
I have been running a non-split database quite successfully for years, but after reading everyone's advice I decided to split my Database. It became very slow and just unable to work with.
I believe there are many small parameters and settings that you can change to improve things, but up to now we are still working the non-split way.
So take your time to properly test the Frontend / Backend setup with multiple users being logged in at the same time.
missinglinq
AWF VIP
- Local time
- Today, 13:15
- Joined
- Jun 20, 2003
- Messages
- 6,420
Having multiple users sharing a single, non-split database, sitting on a network drive, is the sure way to repeated episodes of corruption, as well as speed and timing problems! Multiple users simply have to work off of a split database, with each user having their own copy of the Front End, which contains everything except the data/tables, on their respective hard drives, and a Back End with only the Tables on a shared drive.
Being in forced retirement, I spend 8-10 hours a day here and on other Access forums/newsgroups, and over the past ten years have seen dozens and dozens of reports of non-split apps causing an incredible myriad of problems!
The really insidious thing is that, as in MrHans case, a non-split app can work successfully, for extended periods of time, even years, before the troubles begin! But once it does, they become chronic, which is to say they occur over and over and over again!
Here are a couple of good tutorials on Splitting a Database:
https://www.fmsinc.com/microsoftaccess/DatabaseSplitter/
http://www.hitechcoach.com/index.php?option=com_content&view=article&id=35:split-your-access-database-into-application-anddata&catid=24:design
Linq ;0)>
Being in forced retirement, I spend 8-10 hours a day here and on other Access forums/newsgroups, and over the past ten years have seen dozens and dozens of reports of non-split apps causing an incredible myriad of problems!
The really insidious thing is that, as in MrHans case, a non-split app can work successfully, for extended periods of time, even years, before the troubles begin! But once it does, they become chronic, which is to say they occur over and over and over again!
Here are a couple of good tutorials on Splitting a Database:
https://www.fmsinc.com/microsoftaccess/DatabaseSplitter/
http://www.hitechcoach.com/index.php?option=com_content&view=article&id=35:split-your-access-database-into-application-anddata&catid=24:design
Linq ;0)>
- Local time
- Today, 18:15
- Joined
- Feb 19, 2013
- Messages
- 17,564
This can often be due to the database design. When working across a network it is important to keep the network traffic as low as possible - the same reason web pages do on the internet.
So many times you see forms or reports that are based on a whole table rather than just one or a few related records. Or indexing has not been applied properly, or connections not being maintained. Using domain functions inappropriately or non normalised tables - the list goes on.
I agree CJ, that is what I have and I guess that's part of the problem. But what I don't understand is that I don't have these speed/network related issues in the non-split configuration.
The non-split version is on the same network share.
I believe it has to do with opening and closing the recordlock file, so now I prepared a hook into the backend to see if that helps.
Like I said, I also found out that there are many tweaks possible to improve things (data sheet view in tables, auto correct options etc).
But to go back to the OP and not to hijack this thread, make sure you do some thorough testing ...
The non-split version is on the same network share.
I believe it has to do with opening and closing the recordlock file, so now I prepared a hook into the backend to see if that helps.
Like I said, I also found out that there are many tweaks possible to improve things (data sheet view in tables, auto correct options etc).
But to go back to the OP and not to hijack this thread, make sure you do some thorough testing ...
Yes, I think that's it indeed.
We are in the process of changing servers and upgrading the workstations to Windows 10 and Office 2016, so I decided to wait with splitting until this is finished.
Meantime I'm implementing these various bits and pieces to improve performance on a split database.
If it keeps giving issues on the new infrastructure, I'll open my own threat here
We are in the process of changing servers and upgrading the workstations to Windows 10 and Office 2016, so I decided to wait with splitting until this is finished.
Meantime I'm implementing these various bits and pieces to improve performance on a split database.
If it keeps giving issues on the new infrastructure, I'll open my own threat here
