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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Multiple user access (at the same time)
- Thread starter nshenry03
- Start date
You need to split your database into a back end and several front ends for different users. Data is stored in tables in the back end and linked to from the front ends. Access 2003 even has a wizard to do this for you I believe (although I'm not sure if I would trust it).
HTH,
Alex
It's a magical time of year in Philadelphia. Eagles training camp marks the end of another brutal season of complaining about the Phillies.
HTH,
Alex
It's a magical time of year in Philadelphia. Eagles training camp marks the end of another brutal season of complaining about the Phillies.
Critical issue is avoiding conflicts in a multi-user database after splitting. I have had great difficulty finding help and would be open to any suggestions. I have just finished debugging a 50 user database on Citrix which has similar issues. My experience is...
Tables in a split database are common to all user. Forms, vba code, queries, etc are unique to individual front ends.
If you are using code to pull data from a table, you will generally not have a problem. If you are saving data to tables or are overwriting tables, like using a make table query, you can have conflicts that will crash the program if, for example, the table you are overwriting is the record source for a form or report.
You also need to focus on how you are going to handle your record locking.
I would be happy to share with you any of the code that I have learned from Tek-Tips and such gurus as PHV and CautionMP who go from mountain top to mountain top whilst there are those of us who must trudge down the mountain, thru the valley and up the other side.
Tables in a split database are common to all user. Forms, vba code, queries, etc are unique to individual front ends.
If you are using code to pull data from a table, you will generally not have a problem. If you are saving data to tables or are overwriting tables, like using a make table query, you can have conflicts that will crash the program if, for example, the table you are overwriting is the record source for a form or report.
You also need to focus on how you are going to handle your record locking.
I would be happy to share with you any of the code that I have learned from Tek-Tips and such gurus as PHV and CautionMP who go from mountain top to mountain top whilst there are those of us who must trudge down the mountain, thru the valley and up the other side.
I would add a few more comments.
Once the program goes online, there is possibility of code and data issues. Some just give error messages, some corrupt the database and others crash the program. It is important that you create a login table or some other method that identifies users if there are a large number, so that you can establish exclusive use to make design changes. There are an infinite number of ways that users can operate programs and enter data that a programmer will not anticipate.
Debugging and auditing are a major part of a multiuser database. Documentation and training get stepped up a notch.
New users will not be able to log in while you are in design mode making corrections, however, you can login in design mode while other users are in. You will not be able to save and you can corrupt the database if you attempt to make design changes while other users are in. (based on Access 2000)
If you have multiple front ends on different desktops, you will have a mangement issue in terms of maintaining upgrades. You can use replication, which also has some issues.
We use Citrix which creates a "virtual" front end for each user using a single Access database on the Citrix server. Big improvement, in my opinion, over replication. Biggest problems with replication, dating back to Access 97, was that it created huge files to store and compare data and was a mess reconciling data when the programs crashed. The programmer ends up reconciling data that only the users understand.
That is my 2 cents worth, and good luck.
Once the program goes online, there is possibility of code and data issues. Some just give error messages, some corrupt the database and others crash the program. It is important that you create a login table or some other method that identifies users if there are a large number, so that you can establish exclusive use to make design changes. There are an infinite number of ways that users can operate programs and enter data that a programmer will not anticipate.
Debugging and auditing are a major part of a multiuser database. Documentation and training get stepped up a notch.
New users will not be able to log in while you are in design mode making corrections, however, you can login in design mode while other users are in. You will not be able to save and you can corrupt the database if you attempt to make design changes while other users are in. (based on Access 2000)
If you have multiple front ends on different desktops, you will have a mangement issue in terms of maintaining upgrades. You can use replication, which also has some issues.
We use Citrix which creates a "virtual" front end for each user using a single Access database on the Citrix server. Big improvement, in my opinion, over replication. Biggest problems with replication, dating back to Access 97, was that it created huge files to store and compare data and was a mess reconciling data when the programs crashed. The programmer ends up reconciling data that only the users understand.
That is my 2 cents worth, and good luck.
- Thread starter
- #5
I started out on Citrix in a multi - user environment with both the front and back ends on the citrix server. Am now using just Terminal Services on a 2003 server using Access 2000. The migration was esentially trouble free with the exception of printer management on remote (VPN) users and to solve this I had to write some code to set the printer (seems CITRIX is better at handling printing that TS is presently, at least for remote clients).
Of course I have the data bases split with a front/back end.
The users on the network merely execute a common front end that resides on the '03 server which is linked to the back - end database which resides on the same server.
No problems whatsoever (not a single database crash, not a single corruption, nothing) over the last 5 years with multiple users, even for users at a remote site that access the front end via VPN.
In addition, the applications are very fast, in fact, they rip.
For development, I have a duplicate of the front end/back end on the same server.
The only issue, from a multi-user perspective, that I have run into is record locking. One was related to the service pack level I was initially running and the other I solved with some code that tends to the issue that I gleaned from somewhere on the internet and it works flawlessly.
In this day and age, where you've got large numbers of users, it seems to me that, given the sophistication of Terminal Services, it's beyond me why anyone would choose to maintain front ends on every workstation when all you need is one copy on the server.
Of course I have the data bases split with a front/back end.
The users on the network merely execute a common front end that resides on the '03 server which is linked to the back - end database which resides on the same server.
No problems whatsoever (not a single database crash, not a single corruption, nothing) over the last 5 years with multiple users, even for users at a remote site that access the front end via VPN.
In addition, the applications are very fast, in fact, they rip.
For development, I have a duplicate of the front end/back end on the same server.
The only issue, from a multi-user perspective, that I have run into is record locking. One was related to the service pack level I was initially running and the other I solved with some code that tends to the issue that I gleaned from somewhere on the internet and it works flawlessly.
In this day and age, where you've got large numbers of users, it seems to me that, given the sophistication of Terminal Services, it's beyond me why anyone would choose to maintain front ends on every workstation when all you need is one copy on the server.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question