Storing Data in Access

Access was designed from the start to store data, so (if you have a choice —which is not always the case) it is the place where you should store your data. You may need to use that data to produce Word letters, SharePoint lists, Excel worksheets, or Outlook mail messages, but the data itself should be kept in Access tables, unless there is a very strong reason to store it elsewhere.

One valid exception is storing data in SQL Server back-end databases, using Access as the front end. SQL Server is usually the choice for huge corporate databases, not small-to medium-sized databases used by individuals or small companies, where Access can easily handle the number of records. See Chapter 18 for more information on this option.

Data entry and editing, too, should be done in Access, for the most part, because you can create Access forms that offer an attractive interface for entering and editing data. You can write VBA code that runs from form and control events for purposes of error handling, and create functions that automate repetitive data-processing operations.

In my earlier book, Expert One-on-One Microsoft Application Development, I discussed creating Access applications, with details on using queries, forms, reports, and code. I won't duplicate this information here, but instead in this chapter I concentrate on new or improved features in Access 2007, which enhance the utility of Access forms and reports.

fROCC.DCC

0 0

Post a comment