One of the best practices as specified by Microsoft for Access Development is splitting Access application into 2 parts; Front End that hold all the object except tables and the Back End that holds the tables.
The msdn page links there to the article Splitting Microsoft Access Databases to Improve Performance and Simplify Maintainability that describes the process in details.
It is recommended that in multi user environment the Back End is stored on the server/shared folder while the Front End is distributed to each user.
That implies that each time there are any changes made to the front end they need to be deployed to every user machine.
My question is:
Assuming that the users themselves do not have rights to modify the Front End part of the application what would be the drawbacks/dangers of leaving this on the server as well next to the Back End copy?
I can see the performance issues here, but are there any dangers here like possible corruptions etc?
Thank you
EDIT
Just to clarify, the scenario specified in question assumes one Front End stored on the server and shared by users.
I understand that the recommendation is to have FE deployed to each user machine, but my question is more about what are the dangers if that is not done.
E.g. when you are given an existing solution that uses the approach of both FE and BE on the server. Assuming the the performance is acceptable and the customer is reluctant to change the approach would you still push the change? And why exactly? For example the danger of possible data corruption would definitely be the strong enough argument, but is that the case?
It is a part of follow up of my previous question From SQL Server to MS Access 2007
The only drawback to leaving the individual user specific copies of the FE on the server is network performance. It won't make a difference as far as data corruption.
But you shouldn't share a FE between multiple users. This is prone to corruptions on the FE and other weirdness. Each user should get their own copy of the FE. Also you can't replace it with a new copy while users are using it.
A client was running for years with the FE on individual user folders on the file server but running msaccess.exe in a Citrix cluster. The IT staff didn't want to have anything updating the local hard drives of the Citrix cluster server systems.
As far as deploying the FE see the Auto FE Updater at my website. Huge changes coming in the next week to make it much, much easier for both initial server install and easier user initial install.
To keep the front-end on the server would more or less defeat the purpose of splitting the database. Putting the front-end on the desktop reduces network traffic since the application is not retrieved for each use, and allows the front end database to contain tables with data that is private to each user for storing settings or temporary data.
If you wish to avoid data corruption, it is important that each user should have their own copy of the front-end. Allen Browne offers more details on avoiding corruption in this article
There are a number of utilities available to update the front-end version on the desktop as required, or you can even write such a utility yourself.
I agree with the others. Keeping the fe on the server is not recommended. Just put a batch file on your server that does the push. When you have an update send a shortcut to the batch file via email. That is one of many solutions. Once you set it up it is not a problem.
Seth
As an Access 2007 Programmer using a Front End (FE) that is linked to a Back End (BE) database (a.k.a. Split Database) I have done both of the above. Sending an updated FE to users has other overhead, esp if third party controls or applications are used.
As for Citrix, back in Access 97 days, a Citrix manager was able to allow me to put one copy of the FE in a server file location. It would create a new instance for each user that logged in. We were able to use over 50 users with out any impacts. I must qualify this by saying the Access VBA code used efficient updates and transactions with roll-backs rather than just simple Select statements.
My problem today is Access 2007 running on a Citrix server (Windows 2003).
When I am the only person logged into Citrix, the application ( I picked a large complex report that creates a custom Excel spreadsheet via automation for the test) it runs within 1% as fast as running the FE from my XP workstation, and linking to the BE on the Citrix server hard drive.
But, when two or three people log into the Citrix Server, the same report takes three times as long. However, while two or three people are logged into Citrix, I can run my FE from my XP workstation and it runs exactly like the single-user on citrix.
A FE posted on a shared networked drive, shared by two or three users is NOT advised for this same reason. Access FE are not designed to be shared (* I will spare the details*). That is why people put a FE on each workstation and share one database (BE).
What I find lacking in Citrix is some good step-by-step "how-to" run Access FE on Citrix. Ideally, a single file could be posted. When a user loggs into Citrix, Citrix should make a copy of the FE and assign the resources (for Access) to that user's login.
I think this is exactly what MS Office does automatically or at least has instructions on how to do it.
If such a document exist, please post it. A programmer like myself would love to hand it to the Citrix Administrator. It would solve a lot of problems.
Related
I am tring to create an Access application.
I want the database (tables) to be online and the app (forms, reports) to be installed on each pc.
Is there any possible way to succeed this?
Will I need a dedicated server ?
Alternatively, is there any platform (free or not) that I can upload the whole Access app making it Web app?
I made a research and Sharepoint does not satisfy me at all.
Unfortunately, microsoft does not support Access web apps anymore.
Thanks in advance.
Your best and most low cost is SharePoint tables from an office 365 plan.
Remember, Access web publishing is NOT required if you migrate tables to SharePoint, and then place the front ends on each PC.
So even the most basic office 365 planes support SharePoint tables. (You don’t need Access web publishing for the SharePoint table feature). You one monthly plan of about $7 allows all 20 users to connect with the one account one $7 fee total for all 20 users.
You can’t use “files” like Access accDB ones over the internet with say OneDrive, or drop box etc. The reason for this is these web systems don’t support windows networking. So while you can pull a word file from such system, you cannot EDIT the file on that remote system. When you are done editing word, then you send the WHOLE file back up to the remote system and the word document is OVERWRITTEN.
Of course with Access, if each user were to OVERWRITE THE WHOLE file, then each user would thus always overwrite anything changed by any other user. So these systems do NOT support the ability to update ONLY BITS AND PARTS of the file. It is this “bits” and “parts” updating that allows two users to work at the same time and edit separate rows of data in the ONE file.
So Access is VERY different than the rest of office.
With word, or Excel, then you edit the document and then SAVE THE WHOLE document. That “saving” will thus overwrite the changes made by anyone else. So these “cloud” systems do NOT support the ability to only update “part” of the file – but only the WHOLE file.
Word, Excel etc. thus work on a “whole file” update model. However, Access requires the “special” ability of the windows file system that allows one to update ONLY PART of the file. And even more important is windows file system allows two people to update at the same time as long as they are updating “different” parts of the file.
What the above means is then you have to move the back end data file from a “file” based system to some kind of server database system. That means MySQL, SQL server, or SharePoint tables.
I made a research and Sharepoint does not satisfy me at all. Unfortunately, microsoft does not support Access web apps anymore.
I would not write off this choice. Access web publishing is NOT required for Access to use SharePoint tables. And that table option is VERY nice since such tables even work without the internet connection and will “sync” or “catch up” when you finally do get a decent internet connection. In other words this “sync” type of model is more like email then traditional links to a database.
This web based message system and technology is FAR BETTER than Access ODBC tables since “small” connection breaks that is common over the internet tends to make use of ODBC over the internet rather painful compared to SharePoint tables (they were built from the ground up with the internet in mind, while linked ODBC tables in Access were created 25 years ago, and they did not have the internet back then – so the design considerations of internet were not given to the ODBC choice.
I mean, you can make a car fly, but if you design the machine from the ground up as a plane as compared to a car, the result is a far better machine that flies. So there will be 100’s if not 1000’s of small choices made in the design of the product for its given intended use. So Access was around LONG before the internet – so most options don’t play nice over the internet. However the SharePoint table open is from the ground up based on internet connection technology – ones that often break, or even stop working.
I explain the table migration process to office 365 here:
https://youtu.be/3wdjYIby_b0?list=PL27E956A1537FE1C5
The other choice is to migrate the data to the Web hosting database system. Most web sites usually offer MySQL or SQL server as a database choice. However, ONE BIG detail is you have to find a web hosting provider that allows external ODBC connections. Today, less and less web hosting companies allow raw external connections to the database that drives the web site. (The reason of course is security).
So while say when you go to amazon to buy a book, the web site and web server system can pull information about books etc. from the database system. However, you on the outside cannot connect or link access to the database system that drives Amazon.
So while the web hosted server has full use of the database server, you as an external outside user (not from the web site) do not have such permissions.
So you need to find a provider that includes a database server, but in addition to allowing the web site to grab + pull data from database server, they also allow everyone on the planet who is connected to the wild and crazy internet to ALSO be able to connect to the database server (and by-pass the web site).
So as you can see, this is a big security risk because that database server now has to allow any crazy person on the internet to pull data from that database. I mean, I seen within say 5, or 10 minutes of opening up such database systems, you see 100’s if not 1000’s of logon attempts and people trying to link to your exposed tables! I mean, if all your users can link and see those tables, then so can the everyone else on the wild internet. So in a very short time automated bots will attempt to logon and link to those tables if they find someone crazy enough to “open” up their database system to allowing everyone to “link” or at least try to “link” to those tables.
So fewer and fewer web hosting companies allow external connections to the database that by-pass the web site. You need this by-pass the web site and go direct to database ability. The reason of course is Access is not connecting or linking to the web site, but needs to link DIRECTLY to the database system. (This thus has near nothing to do with the web site – you are to consume the database system, not the web system).
As noted, most simple is SharePoint and office 365. And this choice also has good performance WHEN the file sizes are limited and fit within the SharePoint table limits.
Another choice would be to purchase a monthly SQL Azure plan, and then again migrate your data from Access to SQL server. This setup will also work. They have a number of cool security features (you can restrict what IP address are allowed to connect for example).
Last but not least:
Your internet connection is about 10 times, or even 30 times slower than your normal office network. That means a typical wait time of say 3 seconds with your split application now on your office network will become a wait time of 30, or even 150 seconds if you connect over the internet (150 seconds = 2.5 minutes!!!!!).
This means you have to spend time optimizing the application for this setup. I explain this issue here:
http://www.kallal.ca//Wan/Wans.html
If you don't think this speed issue outlined in the above wans article does not apply to you then I suggest a re-reading it again and again until such time you realize this slower internet issue applies to you. Do the basic math - your internet connection will be 10 to 100 times slower then your cheap local office network. Do take more meds if you don't grasp this issue and don't think it applies to your case and use - it does.
One of the alternative options to Access Web App is PowerApps. It is one of the foremost suggestion to migrate Access Web Apps which is quite easy and powerful.
Just wondering what the best practice is for the front-end portion of a split database. The company has a shared drive that everyone has access to and is where the back-end actually is. Just wondering if it is better practice to distribute a copy of the FE to everyone or if I should just point them in the direction of the FE on the shared drive. The latter seems easier to maintain although I know there is software to help manage FE distribution.
so is it that [distributing a separate copy of the front-end to each user] even still best practice?
Yes, even in 2016 it is not only the best practice, it is absolutely required for reliable operation with multiple concurrent users.
What would the benefit be over having everyone access a single FE file on a shared server?
When multiple concurrent users open the same copy of a front-end database file Access will get confused about the state of open objects (primarily Forms and their associated Recordsets). The data from the back-end can appear to be corrupted, although it may not actually be corrupted at the table level.
When multiple concurrent users each have their own local copy of the front-end file Access does not get confused and the application works correctly. That is the benefit.
The benefit is that all users always have a fresh and updated copy and - in case of a failure - they can just run the shortcut again to have a fresh copy.
This even works in a Citrix environment:
Deploy and update a Microsoft Access application in a Citrix environment
David Fenton recently mentioned in another thread that
"The only proper place for any Access app (since Windows 2000, in fact) is the folder the %AppData% environment variable points to."
I greatly respect David's knowledge, especially in all matters relating to Access, but I'm confused by this statement.
What is the advantage of following this advice, especially in an environment where you are going to have multiple people using the same computer to access your app?
Won't installing to this folder only install the app for one user? And if this is true, won't installing your app multiple times leave multiple, separate copies of your app on the machine? Hard drive space is cheap these days, but I still don't want a front end file and other supporting files (graphics, Word and Excel templates, etc.) copied multiple times onto a machine when one copy will do.
What are your thoughts? Am I missing something key to understanding David's advice?
Yes, this is an issue but the only way around it is, assuming the IT admins allow it, to create a folder in the root of C drive and install the Access FE database file in that folder. That said I'd stil use the Application Data folder even if files are duplicated. As you state hard drives are cheap.
This assumes you don't mean a Terminal Server/Citrix system where users are simultaneously logged into the system.
First off, this is an issue only for a workstation that has multiple users logging on to it. That's pretty uncommon, isn't it?
Second, you admit there's no issue with disk space, so the only real issue is keeping the front end up-to-date, and that issue is really completely orthogonal to the question of where the front end is being stored.
That issue can be addressed by using any of a number of solutions that automatically copy a new version of the front end when the user opens it (if needed). Tony Toews's Auto FE Updater is the best solution I know of. It's quite versatile and easy to use, and Tony's constantly improving it.
So, in short, I don't think there's any issue here at all.
If everything is always the same for every user on a given machine, then multiple copies of a file may not be such a good idea. But when that one exception occurs, you've painted yourself into a corner. They may need a different template version for example.
You seem to be in a rare situation for an Access developer.
You're running into a bit of an issue here, because you're thinking about the environment variable name %appdata%. That variable stores the directory returned by SHGetSpecialFolderPath(CSIDL_APPDATA).
What you're looking for is the directory returned by SHGetSpecialFolderPath(CSIDL_COMMON_APPDATA). There's no environment variable for that directory. This directory is (as the name indicates) common to all users.
The advantage of David's method is that the Access data is protected by NTFS access rights, when it's in CSIDL_APPDATA. A user can only delete his copy. In CSIDL_COMMON_APPDATA, anyone can delete the single shared copy.
It's probably always best to put these advice and tips into perspective. The assumption being made here is if your application is going to be utilized in a multi user mode (that means more than one user in the application of the same time), then it's pretty much assumed that your applications going to be split into two parts. The so called application part (front end), and then the data file only part, or so called backend part.
So, you have a FE and a BE.
In this environment, each individual user within your office will have their own copy of the application placed on their workstation. The BE (data file) is thus assumed to be placed on some share folder on a server.
In the case we're not going to have multiple users running this application, or the application is not really under development, then you really don't need to split your application into two parts. However if you split your application, it means all of your users can safely work and utilize your application while you work on a copy of the next great version of this application release. Without a split environment, you really can't have any workable development cycle.
It is a long time and honored suggestion that if you're going to use access in a multi user environments, each individual user must have a copy of the front end application placed on each individual computer. If you avoid this suggestion, the end result is instability in the general operation of your application.
I have an article here that explains on a conceptual level and doesn't just tell you two split your application, but explains well why you should split your application:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
I have created an MS Access 2003 application, set up as a split front-end/back-end configuration, with a user group of about five people. The front end .mdb sits on a network file server, and it contains all the queries, forms, reports, and VBA code, plus links to all the tables in the back end .mdb and some links to ODBC data sources like an AS/400. The back end sits on the same network file server, and it just has the table data in it.
This was working well until I "went live" and my handful of users started coming up with enhancement requests, bug reports, etc. I have been rolling out new code by developing/testing in my own copy of the front-end .mdb in another network folder (which is linked to the same back-end .mdb), then posting my completed file in a "come-and-get-it" folder, alerting the users, and they go copy/paste the new front-end file to their own folders on the network. This way, each user can update their front end when they're at a 'stopping point' without having to boot everyone out at once.
I've found that when I'm developing now, sometimes Access becomes extremely slow. Like, when I am developing a form and attempt to click a drop-down on the properties box, the drop-down arrow will push in, but it will take a few seconds before the list of options appears. Or there's tons of lag in selecting & moving controls on a form. Or lots of keyboard lag.
Then, at other times, there's no lag at all.
I'm wondering if it's because I'm linked to the same back end as the other users. I did make a reasonable effort to set up the queries, forms, reports etc. with minimal record locking, if any at all, depending on the need. But I may have missed something, or perhaps there is some other performance issue I need to address.
But I'm wondering if there is an even better way for me to set up my own development back-end .mdb, so I can be testing my code on "safe" data instead of the same live data as the rest of the users. I'm afraid that it's only a matter of time before I corrupt some data, probably at the worst possible moment.
Obviously, I could just set up a separate back-end .mdb and manually reconfigure the table links in the front end every time, using the Linked Table Manager. But I'm hoping there is a more elegant solution than that.
And I'm wondering if there are any other performance issues I should be considering in this multi-user, split database configuration.
EDIT: I should have added that I'm stuck with MS Access (not MS-SQL or any other "real" back end); for more details see my comment to this post.
If all your users are sharing the front end, that's THE WRONG CONFIGURATION.
Each user should have an individual copy of the front end. Sharing a front end is guaranteed to lead to frequent corruption of the shared front end, as well as odd corruptions of forms and modules in the front end.
It's not clear to me how you could be developing in the same copy of the front end that the end users are using, since starting with A2000, that is prohibited (because of the "monolithic save model," where the entire VBA project is stored in a single BLOB field in a single record in one of the system tables).
I really don't think the problems are caused by using the production data (though it's likely not a good idea to develop against production data, as others have said). I think they are caused by poor coding practices and lack of maintainance of your front end code.
turn off COMPILE ON DEMAND in the VBE options.
make sure you require OPTION EXPLICIT.
compile your code frequently, after every few lines of code -- to make this easy, add the COMPILE button to your VBE toolbar (while I'm at it, I also add the CALL STACK button).
periodically make a backup of your front end and decompile and recompile the code. This is accomplished by launching Access with the /decompile switch, opening your front end, closing Access, opening your front end with Access (with the SHIFT key held down to bypass the startup code), then compacting the decompiled front end (with the SHIFT key held down), then compiling the whole project and compacting one last time. You should do this before any major code release.
A few other thoughts:
you don't say if it's a Windows server. Linux servers accessed over SAMBA have exhibited problems in the past (though some people swear by them and say they're vastly faster than Windows servers), and historically Novell servers have needed to have settings tweaked to enable Jet files to be reliably edited. There are also some settings (like OPLOCKS) that can be adjusted on a Windows server to make things work better.
store your Jet MDBs in shares with short paths. \Server\Data\MyProject\MyReallyLongFolderName\Access\Databases\ is going to be much slower reading data than \Server\Databases. This really makes a huge difference.
linked tables store metadata that can become outdated. There are two easy steps and one drastic one to be taken to fix it. First, compact the back end, and then compact the front end. That's the easy one. If that doesn't help, completely delete the links and recreate them from scratch.
you might also consider distributing an MDE to your end users instead of an MDB, as it cannot uncompile (which an MDB can).
see Tony Toews's Performance FAQ for other generalized performance information.
1) Relink Access tables from code
http://www.mvps.org/access/tables/tbl0009.htm
Once I'm ready to publish a new MDE to the users I relink the tables, make the MDE and copy the MDE to the server.
2) I specifically created the free Auto FE Updater utility so that I could make changes to the FE MDE as often as I wanted and be quite confident that the next time someone went to run the app that it would pull in the latest version. For more info on the errors or the Auto FE Updater utility see the free Auto FE Updater utility at http://www.granite.ab.ca/access/autofe.htm at my website to keep the FE on each PC up to date.
3) Now when working on site at a clients I make the updates to the table structure after hours when everyone is out of the system. See HOW TO: Detect User Idle Time or Inactivity in Access 2000 (Q210297) http://support.microsoft.com/?kbid=210297 ACC: How to Detect User Idle Time or Inactivity (Q128814) http://support.microsoft.com/?kbid=128814
However we found that the code which runs on the timer event must be disabled for the programmers. Otherwise weird things start happening when you're editing code.
Also print preview would sometimes not allow the users to run a menu item to export the report to Excel or others. So you had to right click on the Previewed report to get some type of internal focus back on the report so they could then export it. This was also helped by extending the timer to five minutes.
The downside to extending the timer to five minutes was if a person stays in the same form and at the same control for considerable parts of the day, ie someone doing the same inquiries, the routine didn't realize that they had actually done something. I'll be putting in some logic sometime to reset this timer whenever they do something in the program.
4) In reference to another person commenting about scripts and such to update the schema see Compare'Em http://home.gci.net/~mike-noel/CompareEM-LITE/CompareEM.htm. While it has its quirks it does create the VBA code to update tables, fields, indexes and relationships.
Use VBA to unlink and re-link your tables to the new target when switching from dev to prod. It's been to many years for me to remember the syntax--I just know the function was simple to write.
Or use MS-Access to talk to MS-Access through ODBC, or some other data connection that lives outside of the client mdb.
As with all file base databases, you will eventually run into problems with peak usage or when you go over a small magical number somewhere between 2 and 30.
Also, Access tends to corrupt frequently, so backup, compact and repair need to be done on an frequent basis. 3rd party tools used to exist to automate this task.
As far as performance goes, the data is being processed client side, so you might want to use something like netmeter to watch how much data is going over the wire. The same principle about indexing and avoiding table scans apply to file base dbs as well.
Many good suggestions from other people. Here's my 2 millicents worth. My backend data is on server accessed through a Drive mapping. In my case, the Y drive. Production users get the mapping through a login script using active directory. Then the following scenarios are easily done by batch file:
Develop against local computer by doing a subst command in a batch file
run reports against last nights data by pointing Y to the backup server (read only)
run reports against end of month data by pointing to the right directory
test against specialized scenarios by keeping a special directory
In my environment (average 5 simultaneous users, 1000's of rows, not 10,000's.) corruption has occurred, but it's rare and manageable. Only once in the last several years have we resorted to the previous days backup. We use SQL Server for our higher volume stuff, but it's not as convenient to develop against, probably because we don't have a SQL admin on site.
You might also find some of the answers to this question (how to extract schemas from access) to be useful as well. Once you've extracted a schema using one of the techniques that were suggested you gain a whole range of new options like the ability to use source control on the schemas, as well as being able to easily build "clean" testing environments.
Edit to respond to comment:
There's no easy way to source control an Access database in it's native format, but schema files are just text files like any other. Hence, you can check them in and out of the source control software of your choice for easy version control/rollbacks.
Or course, it relies on you having a series of scripts set up to re-build your database from the schema. Once you do, it's normally fairly trivial to create an option/alternative version that rebuilds it in a different location, allowing you to build test environments from any previous committed version of the schema. I hope that clarifies a bit!
If you want to update the back end MDB schema automatically when you release a new FE to the clients then see Compare'Em http://home.gci.net/~mike-noel/CompareEM-LITE/CompareEM.htm will happily generate the VBA code need to recreate an MDB. Or the code to create the differences between two MDBs so you can do a version upgrade of the already existing BE MDB. It's a bit quirky but works.
I use it all the time.
You need to understand that a shared mdb file for the data is not a robust solution. Microsoft would suggest that SQL Server or some other server based database would be a far better solution and would allow you to use the same access front end. The migration wizard would help you make the changeover if you wanted to go that way.
As another uses pointed out, corruption will occur. It is simply a question of how often, not if.
To understand the performance issues you need to understand that to the server the mdb file with the data in it is simply that, a file. Since no code runs on the server, the server does not understand transactions, record locking etc. It simply knows that there is a file that a bunch of people are trying to read and write simultaniously.
With a database system such as SQL Server, Oracle, DB2. MySQL etc. the database program runs on the server and looks to the server like a single program accessing the database file. It is the database program (running on the server) that handles record locking, transactions, concurrency, logging, data backup/recovery and all the other nice things one wants from a database.
Since a database program designed to run on the server is designed to do that and only that, it can do it far better and more efficently that a program like Access reading an writing a shared file (mdb).
There are two rules for developing against live data
The first rule is . . . never develop
against live data. Not ever.
The second rule is . . .never develop
against live data. Not ever.
You can programatically change the bindings for linked tables, so you can write a macro to change your links when you're deploying a new version.
The application is slow because it's MS Access, and it doesn't like many concurrent users (where many is any number > 1).
I've created a database in access 2007 that needs to be used by 3 users. I'm stuck because I don't know whether to place a copy on each users' computer or to place it on their SQL server. Placing it on the server would mean one access point which is desirable for data consistency but I don't know whether I need ActiveX. Don't know how to use it either. If I place it one each computer how do I work around the master file updates? Can somebody please break it all down, I'm a NEWBIE!!
Your question seems rather confused to me. You mention a SQL Server, but you don't say your application uses SQL Server for its data storage.
Thus, I can only assume that you have a single MDB or ACCDB file with your data tables and forms and reports all in the one file.
The only proper way to distribute this app is:
split it into front end (forms/reports/etc.) with linked tables that point to the back end (data tables only).
place the back end on your file server and relink your tables to point to the new location of the back end.
give a copy of the front end to each of the 3 users, who will run it from their desktop computers. If you're concerned about distributing changes to the front end, something like Tony Toews's front-end updater is very useful.
Others have jumped in to say that you should put the data in SQL Server, but most 3-user Access apps don't need the power of SQL Server. If you're not given administrative permissions on your SQL Server, it could be quite difficult to continue to alter your application's database.
On the other hand, if your database is going to grow to 1GB or more, or if you have strict security requirements, or if the data in your database is so important as to need completely failproof backups, then SQL Server would be a reasonable data store.
For most homegrown apps, not so much.
The "best" way I've worked this out is using Linked Tables in Access to go to SQL Server (since you stated you have that..?).
Using access as a front end in this scenario isn't the best thing you can do, but with 2007, it's a bit better than if you were a few versions back. Check out this article for info on linking Access into SqlServer:
Import or link to SQL Server data
One easy way is to use the EQL Data plugin: http://eqldata.com
That way you can give a copy of the database to each user, but users can sync the database with other users whenever they want. You can also access your tables and queries on the web.