Microsoft Access

Encyclopedia : M : MI : MIC : Microsoft Access

Microsoft Access (full name Microsoft Office Access) is a relational database management system from Microsoft, packaged with Microsoft Office Professional which combines the relational Microsoft Jet Database Engine with a graphical user interface.

Microsoft Access can use data stored in Access/Jet, Microsoft SQL Server, Oracle, or any ODBC-compliant data container. Skilled software developers and data architects use it to develop powerful, complex application software. Relatively unskilled programmers and non-programmer "power users" can use it to build simple applications without having to deal with features they don't understand. It supports substantial object-oriented (OO) techniques but falls short of being a fully OO development tool.

Microsoft Access was also the name of a communications program from Microsoft, meant to compete with ProComm and other programs. This Microsoft Access proved a failure and was dropped. Years later Microsoft reused the name for its database software.

Contents

1 History
2 Uses
3 Features
4 Development
5 References
6 Further reading
7 See also
8 External links

History

Microsoft Access version 1.0 was released in November of 1992.

Uses

Access is widely used by small businesses, within departments of large corporations, and hobby programmers to create ad hoc customized systems for handling the creation and manipulation of data. Its ease of use and powerful design tools give the non-professional programmer a lot of power for little effort. However, this ease of use can be misleading. This sort of developer is often an office worker with little or no training in application or data design. Because Access makes it possible even for such developers to create usable systems, many are misled into thinking that the tool itself is limited to such applications.

Some professional application developers use Access for rapid application development, especially for the creation of prototypes and standalone applications that serve as tools for on-the-road salesmen. Access does not scale well if data access is via a network, so applications that are used by more than a handful of people tend to rely on a Client-Server based solution such as Oracle, DB2, Microsoft SQL Server, PostgreSQL, MySQL, MaxDB, or Filemaker. However, an Access "front end" (the forms, reports, queries and VB code) can be used against a host of database backends, including Access itself, Microsoft SQL Server, Oracle, and any other ODBC-compliant product. This approach allows the developer to move a matured application's data to a more powerful server without sacrificing the development already in place.

Many developers who use Microsoft Access use the Leszynski naming convention, though this is not universal; it is a programming convention, not a DBMS-enforced rule.

Features

One of the benefits of Access from a programmer's perspective is its relative compatibility with SQL – queries may be viewed and edited as SQL statements, and SQL statements can be used directly in Macros and VBA Modules to manipulate Access tables. Users may mix and use both VBA and "Macros" for programming forms and logic and offers object-oriented possibilities.

The report writer in Access, while capable and up to the task of sophisticated report creation, is not as full-featured and powerful as another popular database report writer – Crystal Reports. MSDE (Microsoft SQL Server Desktop Engine) 2000, a mini-version of MS SQL Server 2000, is included with the developer edition of Office XP and may be used with Access as an alternative to the Jet Database Engine. (*Early versions of MSDE and Microsoft Exchange Server actually use the Jet engine to handle huge volumes of data and place a "fake" application layer for those applications on top of it. Lack of knowledge about this fact has contributed to an undeserved disrespect for Access/Jet family of software products, particularly as regards "large" projects.)

Access' cut and paste functionality can make it a useful tool for connecting between other databases (for example, Oracle and Microsoft SQL Server during data or database conversions). Access comes with various import and export features that allow integration with Windows and other platform applications, several of which can be executed on demand from within applications or manually by the user. For example the very compact SNP format for sharing perfectly formatted reports with people who don't have the full Access software. It can also easily be upgraded to Microsoft SQL Server.

Unlike complete RDBMS's, the Jet Engine lacks database triggers and Stored procedures. Starting in MS Access 2000 (Jet 4.0), there is a syntax that allows creating queries with parameters, in a way that looks like creating stored procedures, but these procedures are limited to one statement per procedure.[link] Microsoft Access does allow forms to contain code that is triggered as changes are made to the underlying table (as long as the modifications are done only with that form), and it is common to use pass-through queries and other techniques in Access to run stored procedures in RDBMSs that support these.

In ADP files (supported in MS Access 2000 and later), the database-related features are entirely different, because this type of files connects to MSDE or Microsoft SQL Server, instead of using the Jet Engine. Thus, it supports the creation of nearly all objects in the underlying server (tables with constraints and triggers, views, stored procedures and UDF-s). However, only forms, reports, macros and modules are stored in the ADP file (the other objects are stored in the back-end database).

Development

The programming language available in Access is, as in other products of the Microsoft Office suite, Microsoft Visual Basic for Applications. Two database access libraries of COM components are provided: the legacy Data Access Objects (DAO), only available with Access, and the new ActiveX Data Objects (ADO).

Microsoft Access is easily applied to small projects but scales inefficiently to large projects if applications are designed poorly.

All database queries, forms, and reports are stored in the database, and in keeping with the ideals of the relational model, there is no possibility of making a physically structured hierarchy with them.

One design technique is to divide an Access application between data and programs. One database should contain only tables and relationships, while another would have all programs, forms, reports and queries, and links to the first database tables. Unfortunately, Access allows no relative paths when linking, so the development environment should have the same path as the production environment (Although you can write your own "dynamic-linker" routine in VBA that can search out a certain back-end file by searching through the directory tree, if it can't find it in the current path).

This technique also allows the developer to divide the application among different files, so some structure is possible.

References

External links

This article was originally based on material from the Free On-line Dictionary of Computing, which is [Foldoc licenselicensed] under the GFDL.

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.