Creating a Database

There are many ways to create a new database file. You may have noticed the Blank Database button in the upper-left corner of the Office Online area in the main Access screen. This button and the Office Button New choice both reveal the Blank Database area in the right section of the main screen. Clicking either of these buttons transforms the main screen, as shown in Figure 34-3. The Blank Database area replaces the list of recently opened databases on the main screen.

Figure 34-3. Enter the name of the new database in the File Name box in the Blank Database area.


Enter the name of the new database in the File Name box in the Blank Database area. By default, Access creates the new database file in whichever Windows folder you most recently opened from within Access. If you want to use a different folder, use the folder icon to the right of the File Name box to browse to the location you want to use.

Access provides a default name of Database1.accdb for new databases. Be sure to provide a name that you’ll recognize. In Figure 34-4, the new database is named MyAccessAutoAuctions.accdb. (Entering the extension .accdb is optional because Access automatically supplies it if you do not.)

Figure 34-4. The new MyAccessAutoAuctions database is created.


When the new database is created, Access automatically opens it for you.

Note

Access 2007 recognizes all previous versions of Access database files. By default, the 2007 format (with the .accdb extension) is used, but you can specify either Access 2000, 2002–2003, or Access 2007 as the default format. Choose Office Button Access Options Personalize, select the Default File Format option, and choose whichever format you prefer. For instance, if much of your Access 2007 work is performed on Access 2000 databases, you should choose the 2000 format to preserve backward compatibility. Users still working with Access 2000 are not able to open Access files created in the .accdb format.

This book uses a mix of Access file formats for its examples. All of the Access Auto Auctions for these chapters in Access 2007 format, but other examples may be in Access 2000 or 2002–2003 formats.


Access 2007 works directly with Access 2000, 2002–2003, and 2007 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 2007. Access examines the database file you’re opening and, if it determines the file must be converted, presents you with the Database Enhancement dialog box shown in Figure 34-5.

Figure 34-5. Opening an obsolete Access data file invokes the Database Enhancement dialog box.


Responding Yes to the Database Enhancement dialog box opens a second dialog box (not shown) asking for the name of the converted database. Selecting No 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 if users are still working with the old database and it cannot be upgraded to Access 2007 format.

If you’re following the examples in this book, note that we have chosen MyAccessAutoAuctions.accdb as the name of the database file you create as you complete this chapter. This database is for our hypothetical business, Access Auto Auctions. After you enter the filename, Access creates the empty database.

Understanding How Access Works with Data

There are many ways that Microsoft Access works with data. 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 is 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 database (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, repairing the tables, 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 could not work with the application while you repair the form or report.

By separating data from other objects, you can fix the erring object while others are still working with the data. After you’ve fixed the problem, you deliver the new changes to the others, and they import the form or report into their local databases.

In addition, there is a more critical reason to separate your data from the interface objects: security. By maintaining the data in its own database, you maintain better control over the information. The back-end database is physically separated from users, and it is unlikely a user can accidentally or intentionally delete or modify the back-end database files. Also, the back-end database is easily backed up and maintained without affecting users.

While you may want to first develop your application with the tables within the .accdb database, later you can use the Database Splitter wizard to automatically move the tables in your .accdb file to a separate Access .accdb file.


..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset