Microsoft Access 2010 Bible

(Rick Simeone) #1

Part I: Access Building Blocks


32


Access 2010 works directly with Access 2000, 2002–2003, and Access 2007.accdb databases.
Earlier Access database files (such as Access 97 or 95) must be converted to 2000, 2002–2003, or
2007 before they can be used in Access 2010. Access examines the database file you’re opening
and, if the file must be converted, presents you with the Database Enhancement dialog box (shown
in Figure 2.6).

Clicking Yes in the Database Enhancement dialog box opens a second dialog box (not shown),
which asks for the name of the converted database. Clicking No in the Database Enhancement dia-
log box opens the obsolete database in read-only mode, enabling you to view, but not modify,
objects in the database; this process is sometimes referred to as enabling the obsolete database.
Choosing to enable an obsolete database is sometimes necessary when you must understand the
design of an old database, but users are still working with the old database and it can’t be upgraded
to Access 2010 format.

If you’re following the examples in this book, note that I’ve chosen MyCollectibleMiniCars.
accdb as the name of the database file you create as you complete this chapter. This database is
for the hypothetical business, Collectible Mini Cars. After you enter the filename, Access creates
the empty database.

Microsoft Access works with data in numerous ways. For simplicity, most of the examples in this book
use data stored in local tables. A local table is contained within the Access .accdb file that’s open in
front of you. This is how you’ve seen examples so far.

In many professionally developed Microsoft Access applications, the actual tables are kept in a data-
base (usually called the back end) separate from the other interface objects (forms, reports, queries,
pages, macros, and modules). The back-end data file stays on a file server on the network, and each
user has a copy of the front-end database (containing the forms and reports) on his computer. This is
done to make the application more maintainable. By separating the data and their tables into another
database, maintenance work (building new indexes, updating reports, and so on) is more easily done
without affecting the remainder of the system.

For example, you may be working with a multiuser system and find a problem with a form or report in
the database. If all the data and interface objects are in the same database, you have to shut down the
system while repairing the broken form or report — other users can’t work with the application while
you repair the form or report.

By separating data from other objects, you can fix the errant object while others are still working with
the data. After you’ve fixed the problem, you deliver the new changes to everyone, and they import the
form or report into their local databases. Splitting a database also makes it much easier to back up an
application’s data without affecting the application’s user interface.

You may want to first develop your application with the tables within the .accdb database. Then, later,
you can use the Database Splitter Wizard to automatically move the tables in your .accdb file to a
separate Access .accdb file. This process is explained in Chapter 16.

How Access works with data

Free download pdf