Microsoft Office Tutorials and References
In Depth Information
Chapter 2: Sharing the Fun: Managing Multiuser Access
Chapter 2: Sharing the Fun:
Managing Multiuser Access
In This Chapter
✓ Sharing an Access database over a LAN
✓ Dividing your database into front and back ends
✓ Editing data when someone else may be editing the same record
Y our database probably contains such terrific information that lots of
people in your organization want to use it. If the database stores
customer names and addresses, for example, your colleagues may want to use
this information. Also, wouldn’t it be great if only one person had to enter
an address correction in a shared address book instead of everyone having
to maintain a separate one?
Well, Access has been a multiuser database right from the beginning. Many
people can get at the information in your database. Here’s how:
✦ Everyone can use Access to open the database. If your computer is on
a local area network (LAN), you can store your Access database on a
shared network drive, and other people can run Access and open your
database. This option works for only a small number of users, however.
✦ People can see the database information via web-based forms. You
can allow anyone on your LAN (anyone who has access to the database
file, that is) to see or edit database information by using a web browser.
Book IX, Chapter 3 describes how to use Access with SharePoint to
create web-based forms.
✦ You can store your data in a big, industrial-strength database server
application. If your database gets really large, or if you want a lot of
people (more than, say, 15 or 20 people) to be able to see and maintain
it simultaneously, Access may not be able to handle the load. This isn’t
a big problem. Move the tables to a database server program, such as
Oracle or SQL Server, and continue to use your Access queries, forms,
or reports to work with it. You just link your Access database to the
tables in the database server. Because this situation is increasingly
common, Access 2013 comes with an option to migrate the data to a
SQL Server database, which we describe in Book IX, Chapter 2.