Microsoft Access Team Blog : Engine

Beginners guide to ODBC

Clint Covington — Fri, 19 Jun 2009 11:13:08 GMT

The folks @ UtterAccess have produced an useful article titled The Beginner’s guide to ODBC.

This is an attempt to equip the developers who want to use Access as a front-end client to any RDBMS (Relational DataBase Management System) backend (ie, SQL Server, DB/2, Oracle, MySQL, PostgreSQL) with the right questions to explore and ask during design and development. As we cannot cover every special case or all the nuisances that each developers must deal with, it is hoped that,by reading over this document, you will be better equipped to find the needed answers for your specific case. The article assumes that you are familiar with developing an Access application, understand the fundamentals of data types used in Jet and VBA and know basic SQL and is familiar with Data Access Objects (DAO) library and/or ActiveX Data Objects (ADO) library, but are otherwise new to working with ODBC data sources. The objective is to provide you with a set of questions about design and development and know how to ask them.

The first thing that you should be familiar with is potential issues that can crop up when developing against a RDBMS. This is, in no way, a complete list, but hopefully broad and high-level enough to give you an idea of where to start in investigating or anticipating any problems they that you may encounter in development.

Accessing external data using the IN clause

robcooper — Fri, 27 Mar 2009 13:36:00 GMT

Someone sent us a question the other day about one of my favorite dark corners in Access and we thought it might be interesting to dive into this area a little.

Microsoft Access SQL supports two uses of the IN keyword. The most commonly used case is as part of the WHERE clause of a SQL statement to provide a list of values used as criteria. Using the Customers table in the Northwind 2007 sample database as an example, this might look something like:

SELECT [First Name], [Last Name], [State/Province]
FROM [Customers]
WHERE [State/Province] IN ('WA', 'CA', 'NY')

This query returns the names of customers that live in WA, CA, or NY. This keyword provides a nice alternative to the OR clause which would require repeating the field name.

The other use of the IN keyword is as part of the SELECT statement or FROM clause, and is called the IN clause. The IN clause is used to access external data, and can be used in place of linked tables. For example, let's say that you had a SQL Server database that is used as part of an application, but you don't want to maintain a DSN to connect. You could use the IN clause in a query that uses a DSN-less connection to quickly read data from the external table. For example:

SELECT * FROM ExternalTable
IN '' [ODBC;Driver={SQL Server}; Server=ServerName; Database=DatabaseName; Trusted_Connection=Yes]

It is possible to create a linked table that uses a DSN-less connection, but creating the table requires code. Also, unlike a SQL pass-through query, this query is executed by the Access database engine which means that the resultset may also be updateable. Furthermore, there is a certain simplicity or elegance about this technique that I think is cool. Incidentally, there is another syntax for the IN clause, but I prefer this one.

So far so good, but since the IN clause is part of the FROM clause of a query, it can also be used other places where the FROM clause can be used. For example, in a make table query to create a local copy of data in an external table:

SELECT * INTO LocalTable
FROM SourceTable
IN '' [ODBC;Driver={SQL Server}; Server=ServerName; Database=DatabaseName; Trusted_Connection=Yes]

Or, in an append query using the INSERT...INTO statement to move data from the local database into another database. Note that the connection string used in this example is to another Access database.

INSERT INTO DestinationTable (DestinationField)
IN '' [;DATABASE= C:\Users\Rob\Documents\Northwind 2007.accdb]
SELECT SourceField FROM SourceTable

You could even use an append query with multiple IN clauses to concatenate two text files:

INSERT INTO [File2.txt] (Field1)
IN '' [TEXT; FMT=Delimited; HDR=YES; DATABASE= C:\Users\Rob\Documents;TABLE=File2.txt]
SELECT Field1
FROM [File1.txt]
IN '' [TEXT; FMT=Delimited; HDR=YES; DATABASE= c:\Users\Rob\Documents;TABLE=File1.txt];

These are just a few examples of how you could use the IN clause to quickly work with external data. By using different connection strings for the external data sources, you could do some pretty cool stuff.

New Access 2007 Technical Article

robcooper — Wed, 20 Aug 2008 20:03:43 GMT

Aleksandar Jakšić, who is one of the testers on our team, has written an article that shows you how you can use the Access Database Engine from native applications written in C/C++.

The article shows you how to to the Access Database Engine using C or C++, but has a great discussion of the data stack used by Access and some of the different components of the engine. He also breaks down the different methods for accessing data using native technologies such as DAO, ADO, OLE DB, and ODBC. The article provides great insight about the engine and the mechanisms that are used to connect to it, regardless of whether you are writing native code.

The article is available on MSDN:

Developing Access 2007 Solutions with Native C or C++
http://msdn.microsoft.com/en-us/library/cc811599.aspx

Adding multiple attachments from a folder

James K. Rivera — Fri, 01 Aug 2008 00:55:00 GMT

Rob Cooper recently made a post, Adding Attachments from a Folder, which shows how to add a single attachment file per row. But what if you wanted to add more than one file? One (highly contrived) scenario would be to add all of the files in a folder to one row, and do so recursively if requested, similar to Rob's example.

What follows is some VBA code to do this, which borrows a bit from Rob's post and a bit from one of my earlier posts. However, I should point out this (again, highly contrived scenario) is meant only as an example and not something I would recommend doing, because if you are adding more than just a few files you can (ok, WILL) bloat your database very quickly, and in doing so can negatively impact performance and potentially hit the two gigabyte file size limit very quickly (see Access 2007 Specifications for details on database file size and object limitations).

First, to use the following sample code you will need to do some setup. Create a new table, add the following fields, and save it as Table1:

Table1

Field Name	Data Type
ID	Autonumber (Primary Key)
FolderPath	Text
Files	Attachment

Next, open the VBE window (ALT+F11) and insert a new module (Insert -> Module), and paste in the following code:


' ------------------------------------------------------------------------- 
' Procedure : StoreFilesInTable 
' Purpose   : Adds all files matching the specified file mask from the 
'           : specified folder to an attachment field. 
'           : Each row in the represents all files stored from the folder. 
' Arguments : strFolder - The path to the folder stored in the attachment field. 
'           : strTable  - The name of the table containing the attachment field. 
'           : strPathField - The name of the field for the archived folder. 
'           : strAttachmentField - The name of the attachment field. [Files] 
'           : strPattern - File mask. [*.*] 
'           : blnIncludeSubfolders - Recurse into subfolders. [False] 
'           : db1 - The database to operate on.  [CurrentDb] 
' Comments  : The db1 param is included so this can be used to store files in 
'           : a separate database, since using the attachment field this way 
'           : can quickly push a database beyond the 2gb file size limit. 
' ------------------------------------------------------------------------- 
Public Function StoreFilesInTable( _ 
                ByVal strFolder As String, _ 
                ByVal strTable As String, _ 
                ByVal strPathField As String, _ 
                Optional ByVal strAttachmentField As String = "Files", _ 
                Optional ByVal strPattern As String = "*.*", _ 
                Optional ByVal blnIncludeSubfolders As Boolean = False, _ 
                Optional ByRef db1 As DAO.Database) 
    Const CALLER = "StoreFilesInTable" 
    On Error GoTo StoreFilesInTable_ErrorHandler 
    Dim strFilePath As String 
    Dim rstParent   As DAO.Recordset2 
    Dim rstChild    As DAO.Recordset2 
    Dim fldAttach   As DAO.Field2 
    ' These objects require a reference to the "Microsoft Scripting Runtime" 
    ' but are defined as "Object" instead to use late binding and avoid that. 
    ' If you've added the reference, remove the "Object" and uncomment the 
    ' following lines to get the intellisense autocomplete for these objects. 
    Dim objFso       As Object ' Scripting.FileSystemObject 
    Dim objFolder    As Object ' Scripting.Folder 
    Dim objSubFolder As Object ' Scripting.Folder 
    Dim objFile      As Object ' Scripting.File 
    ' If the user did not specify a database, use the current one. 
    If db1 Is Nothing Then Set db1 = Application.CurrentDb 
    ' Instantiate the FileSystemObject. 
    Set objFso = CreateObject("Scripting.FileSystemObject") 
    ' Make sure the folder path always ends with a "\". 
    If (Right(strFolder, 1) <> "\") Then strFolder = strFolder & "\" 
    ' Make sure the folder exists. 
    If Not objFso.FolderExists(strFolder) Then 
        MsgBox "Folder does not exist: " & strFolder, _ 
        vbExclamation, CALLER 
        Exit Function 
    End If 
    ' It exists, so get the folder object. 
    Set objFolder = objFso.GetFolder(strFolder) 
    ' Open the table containing the attachment field 
    Set rstParent = db1.OpenRecordset(strTable) 
    rstParent.AddNew 
    rstParent.Fields(strPathField).Value = objFolder.Path 
    ' Get the first file in this directory. 
    strFilePath = Dir(strFolder & strPattern) 
    ' Store each file that meets the pattern 
    While (Len(strFilePath) > 0) 
        Set rstChild = rstParent.Fields(strAttachmentField).Value 
        rstChild.AddNew 
        Set fldAttach = rstChild.Fields("FileData") 
        fldAttach.LoadFromFile strFolder & strFilePath 
        rstChild.Update 
        rstChild.Close 
        strFilePath = Dir() ' Get the next file 
    Wend 
    ' Commit the new row with the attachments field populated 
    ' with all of the files from the current folder. 
    rstParent.Update 
    ' Recurse into subfolders if requested. 
    If (blnIncludeSubfolders) Then 
        For Each objSubFolder In objFolder.SubFolders 
            StoreFilesInTable objSubFolder.Path, strTable, _ 
                              strPathField, strAttachmentField, _ 
                              strPattern, blnIncludeSubfolders, db1 
        Next 
    End If 
Cleanup: 
    rstParent.Close 
    Set rstParent = Nothing 
    Exit Function 
StoreFilesInTable_ErrorHandler: 
    Debug.Print "Error # " & Err.Number & " in " & CALLER & " : " & Err.Description 
    MsgBox Err.Description, vbCritical, "Error # " & Err.Number & " in " & CALLER 
    GoTo Cleanup 
End Function 'StoreFilesInTable

Here is a short routine to help you test the above code. You will need to change the "<YourUserName>" to your login name, or just change the whole path in the strRootFolder string constant to the folder you want to store in the table. Note that I've set the blnIncludeSubfolders parameter to False to keep you from inadvertently bloating your database, but you can set it to True if you want to include all of the subfolders, too.


Sub TestStoreFilesInTable() 
    Const strRootFolder As String = "C:\Users\<YourUserName>\Pictures\" 
    StoreFilesInTable strRootFolder, "Table1", "FolderPath", "Files", "*.jpg", False 
    MsgBox "Done adding files from: " & vbCrLf & strRootFolder & "*.jpg", _ 
        VbMsgBoxStyle.vbInformation, "TestStoreFilesInTable" 
End Sub

Writing a Count(Distinct) Query in Access

robcooper — Thu, 20 Sep 2007 00:43:00 GMT

We received a question from a reader named Eric week before last about how to write a Count(Distinct) query in Access. In other database applications such as SQL Server, Oracle, and MySQL, the Count(Distinct) aggregate is used to count the number of unique items in a given rowset. For example, consider a table on SQL Server named tblColors, such as:

Color	Value
Red	5
Green	2
Blue	8
Orange	1
Red	8
Green	6
Blue	2

To get a count of the number of unique colors in the table, you could write a query such as:

SELECT Count(Distinct Color) AS N FROM tblColors

This would return the value 4 as there are four unique colors in the Color field in the table. Unfortunately, the Access Database Engine does not support the Count(Distinct) aggregate. To return this value from an Access table, you would need to use a subquery such as:

SELECT Count(*) AS N FROM (SELECT DISTINCT Color FROM tblColors) AS T;

Now let's say that you also want to include another aggregate value such as a Sum, and want to group by some value, in this case, Color. On SQL Server, you could write this query as:

SELECT Color, Sum(Value) AS Total, Count(Distinct Color) AS N FROM tblColors GROUP BY Color

This provides the following results:

Color	Total	N
Blue	10	1
Green	8	1
Orange	1	1
Red	13	1

Now, if you're asking whether or not this should return the value of '1', the answer is yes. As I understand it, the Count(Distinct) here can be used as a test to verify the results of a given query.

If your data is on a server that supports Count(Distinct), you might be able to use a pass-through query to retrieve the results. If you are working with Access data, this becomes a bit more challenging.

Since we used subqueries for the previous query, we'll need to do the same here. The trick however is that we need to use two subqueries as shown in the following SQL:

SELECT C.Color, Sum(C.Value) AS Total, T2.N FROM (SELECT T.Color, Count(T.Color) AS N FROM (SELECT DISTINCT Color, Count(*) AS N FROM tblColors GROUP BY Color) AS T GROUP BY T.Color) AS T2 INNER JOIN tblColors AS C ON T2.Color = C.Color GROUP BY C.Color, T2.N;

You'll recognize the inner-most subquery as the subquery we used in the initial problem. This is then rolled into the outer-most subquery to return the number of colors per group.

Thanks to Eric for the question and to Michael Tucker on the Access test team for the help!

Access Database Engine Redistributable

Zac Woodall — Fri, 10 Aug 2007 04:01:00 GMT

I was looking for this in search results today and realized that it isn't showing up in the rankings (or maybe it does, but the name isn't very intuitive). The new Access 2007 database engine (which reads and writes .accdb files) is available in redistributable format for those who need to code against the file directly, bypassing Access/VBA.

New, More Complete Access Overview

Erik Rucker — Thu, 27 Jul 2006 14:21:00 GMT

Way back in October, I posted an overview of Access. We've finally got a complete customer-ready overview for the product that will be going up on the Access site at http://www.microsoft.com/access. If you'd like a printable version of this paper, it is available here. This takes longer than you might imagine, so I thought I'd post it here as well. Even though I understand many of you are looking for more technical details, this blog is fairly widely read and I know there are many who would like the high-level story. We'll be back to the technical details in the next post.

Executive Summary

Microsoft® Office Access has achieved broad success by enabling information workers to perform data-tracking tasks that otherwise would require the time and expertise of professional programmers and database administrators. In addition, professional developers have found that Office Access can save time and meet business requirements for many applications. IT departments can take advantage of Access capabilities by providing support and management of the Access applications being developed in their organizations. Microsoft is making significant investments in Microsoft Office Access 2007, redesigning the user interface and interactive design tools to make them even more approachable to entry level Access users. Integration with Microsoft Windows® SharePoint® Services will make Office Access 2007 a great collaboration tool, while enabling the data to be stored on enterprise servers for better manageability.

Meeting the Varied Database Needs of an Organization

Relational database technology has had an immense impact on business in the few decades since it was first developed. The vast majority of business transactions are now recorded, tracked, and analyzed using data stored in relational systems. However, enterprise-level database applications, such as sales accounting, inventory control, and human resources management, represent only a portion of any organization’s total information management requirements.

One way to categorize the data-tracking needs of an organization is according to the number of people who work with the data. Some information is used only by individuals, some is used by small work groups, some by entire departments, and some by larger cross-departmental groups within the organization or in the wider community of partners and customers. The need for data security often varies with the size of the group affected, although some individual or small-group applications can require stringent security.

Another key factor to consider is the impact of an interruption in the availability of the data. Some data needs to be reliably available at all times, and some data can intermittently become unavailable without significantly impacting the mission of the organization.

Microsoft Office Access can play a useful role in meeting a wide range of data-tracking requirements. In some cases, the scalability, availability, reliability, or security requirements may demand a server-based engine such as Microsoft SQL Server™. However, even when the data is managed by a non-Access engine, Access forms, reports, and queries can still be useful and safe for creating user interfaces with the data.

Broad Market Success

By meeting the needs of a large and diverse population of users, Microsoft Office Access has achieved greater acceptance in the marketplace than any other database product. Information workers with little or no formal training in programming or database design have been successful in using the wizards and graphical tools in Access to develop useful database applications.

(Click image to enlarge)

Figure 1. Order form in Microsoft Office Access 2003

Over 1.4 million Access database templates were downloaded from the Microsoft Office Online Web site, www.office.microsoft.com, in 2004. The MSDN® Office Developer Center Access portal logged more than 3 million page views and downloads in 2004, averaging approximately 80,000 unique users per month.

An independent Web site, www.utteraccess.com, which provides forums supporting Access, has registered over 90,000 members and has logged over 800,000 posts. On an average day, the Utteraccess.com site records over 500,000 page views, 100 new registered users, and 1,000 new posts.

A study of small and midsize companies conducted by Crestwood Associates in August 2004, found Access to be the leading database program, with 22 percent of respondents reporting that they used applications built with Microsoft Office Access. This study found that Access was used more than twice as much as the second-place product.

From Lists to Relational Databases

Automated spreadsheet applications such as the Microsoft Office Excel® spreadsheet software have existed since the beginning of the personal computer to meet the very common need for information workers to visualize and manipulate tabular data. Modern Web-based collaborative applications such as Windows SharePoint Services also support the creation of custom lists that can be created and maintained using browser-based interfaces. Office Excel provides more extensive calculation and charting capabilities, while Windows SharePoint Services makes it easier to share data across teams. Neither product, however, provides the advantages of true relational database storage. For example, set-based relational queries or bulk updates are not directly supported.

As a list-based application becomes more complex, the need emerges to transfer the data to normalized relational tables that can then be queried and manipulated using Structured Query Language (SQL).

When lists evolve to relational data, Office Access enables information workers to quickly establish a database application to track the information with increased efficiency. Several dozen database templates are available from Office Online to provide models for solving common data-tracking tasks. In addition, Access includes wizards and friendly user interface features to ease the creation of relational data structures and the queries, forms, and reports needed to work with the data.

(Click image to enlarge)

Figure 2. New user interface for Office Access 2007

Microsoft Office Access 2007 has been completely redesigned since Office Access 2003 to further improve the ease of use for information workers who have no coding expertise and very limited database knowledge. The user interface is results-oriented and context-sensitive to expose the features the user needs at the right time. Furthermore, new pre-built solutions (templates) are available and are easily accessible at startup.

Microsoft Office Access, SQL Server, Visual Studio, and the .NET Framework

Microsoft offers a range of products that enable organizations to solve problems by entering, manipulating, and querying relational data. These products include the database engines that directly store and retrieve data, as well as application development tools that enable users to interact with the database engines.

Microsoft Office Access uses a database engine that can store data directly and that can also mediate storage and retrieval of data using other database engines, including Microsoft SQL Server. The Access application development tools can be used either with the Access database engine or directly with the SQL Server database engine.

For most database applications that are used only by individuals or small workgroups, Microsoft Office Access and its database engine can provide valuable solutions while keeping the cost of development low. Users can often solve data-tracking problems using Access, without requiring professional technical support. However, professional design reviews and occasional consultation can significantly improve the quality of Access solutions. For applications requiring greater scalability, availability, or security, SQL Server is an alternative to the built-in database engine of Access for data storage, although Access can still be used to develop user interface objects.

For applications that require a multi-tiered or service oriented architecture, or that require an HTML-based user interface, the Microsoft Visual Studio® development system and the Microsoft .NET Framework may be preferred. The .NET Framework is an integral component of the Microsoft Windows operating system that provides a programming model and runtime for Web services, Web applications, and smart client applications.

Office Access allows problems to be solved relatively quickly and effectively by users who understand the problems well, but who often do not have the resources or the time to develop a more extensively architected and engineered solution.

Case Study: Tracking Product Inspections with Microsoft Office Access

Ken Stewart is the Chief Financial Officer at a company that supplies linens to restaurants and medical clinics. The company has about 150 employees, four of whom work in the accounting department tracking the company’s data. Until two years ago, quality control inspectors were using Excel spreadsheets to record and tally the results of their daily product inspections. They were creating new spreadsheets for each day’s data, recording the number of rejected products and the operators who had worked on them. The accounting department found these spreadsheets hard to summarize into useful reports and noticed that it was easy for the inspectors to make invalid entries in the spreadsheets.

Stewart decided to try using Microsoft Office Access to create a better system, and although he had no prior programming experience, he was able to put together an Access application that solved the problems the accounting department was having. The solution is still in use today. He created data entry forms that helped users ensure that all the required data was entered and formatted properly, and he built reports that summarized the data in useful ways.

Stewart used less than an hour of a consultant’s time to help him organize the data properly into several related tables, and he found that he could create the queries, forms, and reports he needed by using the Access wizards and then modifying a few properties in the graphical designers. When Stewart got stuck trying to do something he couldn’t find explained in the Access help topics, he used Internet searches to locate examples from others who had solved similar problems. He is now considering setting up another Access application to help with the company’s hiring process.

How Office Access Empowers Information Workers

Microsoft Office Access provides a highly integrated set of tools that can be used together to create tables for data storage, links to external data sources, queries for retrieving and manipulating data, forms for data entry, reports for aggregating and analyzing data, macros to automate common tasks, and Microsoft Visual Basic® for Applications (VBA) code for creating advanced customizations. The following sections give an overview of how these Access objects enable users to meet their business requirements, and how Microsoft is enhancing these objects for Office Access 2007.

Native and Linked Tables

Access supports two fundamentally different ways of creating database tables. Users can create new tables in an Access database, or they can create links to existing data. These links appear and behave just like native tables. This support for creation of linked tables is key to the tremendous ease with which Access users can navigate, combine, and update information from multiple existing data sources, while still being able to create and maintain their own new data containers.

The Access database engine can work with its own native tables or with tables it links to using Open Database Connectivity (ODBC) or installable index sequential access method (ISAM) drivers. ODBC provides connectivity to all the common relational database servers, including Microsoft SQL Server, Oracle, IBM DB2, Informix, and Sybase.

Access project files, also called ADPs or .adp files, provide an alternative to using the Access database engine by allowing an Access application to connect directly to the tables in a SQL Server database. ADPs will continue to be supported in Office Access 2007. To take maximum advantage of the new features in Office Access 2007, Microsoft recommends the use of linked tables to connect to SQL Server data.

When Access was introduced, installable ISAM drivers were used primarily for linking to the prevailing desktop databases¾Paradox, dBase and FoxPro¾or to data in Lotus and Excel spreadsheets. Since then, drivers were added to connect to Microsoft Exchange Server data and to HTML tables. In addition, ODBC support helps connect to many corporate database systems, such as accounting systems, Human Resources (HR), sales, and more.

In Access 2003, a significant advance occurred when Microsoft introduced drivers that connect to data stored in Windows SharePoint Services. This was significant because these drivers call a component that sends and receives SOAP messages to the Web Services interfaces in Windows SharePoint Services. By enabling users to link to SharePoint lists, Access allows queries, forms, and reports to treat SharePoint lists as if they were standard relational tables.

In Office Access 2007, Access will move from using the Jet database engine (currently part of Windows) to a version that will be completely under the control of the Access development team. The standard Jet database engine will continue to be available for applications that need it, but the new Access database engine¾which will be 100 percent backward compatible with Jet¾will add Access-specific features. These features will include new capabilities that will enhance compatibility between Access and Windows SharePoint Services. In addition to linking to data in Windows SharePoint Services as they do now, Access users will be able to take this data offline in a local Access database, work with the data locally, and then reconnect to the SharePoint site to upload any changes. Any conflicting data changes made by other users will be handled by a conflict resolution wizard.

Tables in Office Access 2007

Office Access 2007 will make the creation of native Access tables more intuitive, especially for users who are familiar with Excel. In fact, users will be able to copy and paste a range of cells from Excel into Access and have the table schema inferred automatically. Office Access 2007 will also enhance the grid-like datasheet view with new filtering, sorting, and totaling features.

Figure 3. Excel-like experience for Access tables

Data Entry Forms

Access forms are unique in the way they intuitively support data operations. Record selectors, navigation buttons, multicolumn combo boxes and list boxes, as well as a rich set of data-oriented controls, properties, and events, make it very fast and easy for information workers and developers to create full-featured user interfaces for data entry. Unlike other forms packages that focus on easing the creation of Win32® Windows applications and controls, with data binding requiring separate objects, Access forms provide an abstraction layer that is directly related to the underlying data.

Office Access 2007 features a new what-you-see-is-what-you-get (WYSIWYG) forms design interface. Users can design and modify the form layout in real time with live data on the screen—and preview the form as they build it. The new release will also introduce a new split view in which one part of the form will show a series of rows and the other part will show all the details from the selected row.

Office Access 2007 will include new controls for entering and displaying rich text and for selection of dates from a drop-down calendar. It also introduces a new method of data collection based on integration with the Microsoft Office InfoPath® information gathering program or HTML forms sent out in e-mails. When completed forms are received by return e-mail messages, the data is automatically entered into Access tables.

(Click image to enlarge)

Figure 4. E-mail data collection

Reports

Perhaps the most well-known feature in Access is its wizard-supported reporting engine. Access uses a “banded” reporting model that enables easy creation of reports with nested levels of grouping, sorting, and totaling. The report designer is similar to the form designer, with graphical tools that allow reports to be created by dragging and dropping fields from the selected data source.

Office Access 2007 will debut dramatic improvements to the report design experience by introducing a completely new Layout view for reports (and for forms, too). In Layout view, the live data will appear while the report is being designed, and it will be much easier to move and resize blocks of data, with the results immediately visible. Selecting data for the report will also be easier, with related tables becoming available for selection automatically after an initial table is chosen. The user interface for specifying grouping and sorting will be significantly improved as well.

(Click image to enlarge)

Figure 5. WYSIWYG report editing

Another innovation in Office Access 2007 will be the ability to re-run a wizard to modify an existing report instead of requiring users to start from scratch each time they run the wizard. Microsoft expects that many new Access users will discover the power of Access reporting and will quickly become proficient.

Figure 6. Group, sort, and total pane

Queries

As a true relational database management system, Access includes a query processor that efficiently executes commands written in Structured Query Language (SQL). In addition, Access provides a variety of wizards and graphical tools that enable untrained information workers to construct and make use of these queries. In fact, fully functional applications handling data entry and reporting can be created by users with no knowledge of SQL. A graphical drag-and-drop query designer allows users to combine data from multiple tables, including linked tables, and from other saved queries. By setting properties or running wizards, users can easily create complex queries that calculate totals and averages, apply multiple criteria and sorts, pivot data, find top values or unmatched values, and perform updates, inserts, and deletions. In addition, users can create parameterized queries that use criteria based on values supplied at run time, including values automatically picked up from Access forms.

Access builds and executes many types of queries in the background without users even realizing that queries are being created. For example, reports run multiple queries to create nested groupings, subtotals, and totals. Forms automatically generate update, insert, and delete queries as data operations are performed. Sub-forms automatically filter the displayed records or add missing values to new records, based on data displayed in the main form in which the sub-form has been embedded. Lookup Wizards create queries that display related data from another table when data in the main table is viewed. These are all tasks that require skilled query construction in other development environments.

By enabling users to view the SQL code that is created by the wizards and graphical tools, Access also provides excellent opportunities for learning SQL. For experienced SQL coders, advanced techniques such as outer joins and correlated sub-queries are fully supported.

In Office Access 2007, new processing capabilities combined with new options in the Lookup Wizard will enable users to easily display and update data based on many-to-many joins without needing to understand the underlying table and query structures. For example, users will be able to assign multiple people to a task or multiple tasks to a person after creating only two tables, one for people and one for tasks. In the background, Access will automatically create the additional junction table needed to store pairings of people and tasks and the queries needed to retrieve and store the data. A new drop-down list control with check boxes permitting multiple selections will facilitate data entry. In addition, users will easily be able to create append-only columns that allow them to add a series of date-stamped comments to what appears to be a single memo field. The multiple entries will be stored in the background, in a separate table from which they can be filtered and sorted as needed. A similar new data structure will be used to store file streams efficiently as one or more attachments to database rows.

(Click image to enlarge)

Figure 7. Multi-value fields

Macros

Access macros are created in a declarative programming environment that does not require writing any code. Access provides a set of parameterized macro actions for performing common operations, such as opening forms and reports, executing queries, finding records, or importing and exporting data. Users build macros by selecting from lists of options, and Access macros can include conditional branching logic. Macros can be set to run automatically in response to a wide range of user behaviors.

In Office Access 2007, macros will be significantly enhanced with features that previously were available only when programming with VBA code. These enhancements include better support for error handling and debugging, as well as the ability to assign values to variables.

It will be possible to build full-featured Access applications that run even with all VBA code disabled and which, therefore, can be safely e-mailed or downloaded. In fact none of the templates that will ship with Office Access 2007 will contain VBA code. This code-free option will be supported by new macro actions and also by new user interface features. For example, it will be possible to configure a combo box to allow users to add new items to the drop-down list by automatically opening a designated dialog form and then requerying the list when a new item is entered¾all without needing to create any VBA code.

Figure 8. Macro design in Access 2007

Modules

For advanced customization, Access fully supports the use of VBA functions and subroutines. Functions can be called from Access queries to perform complex data processing, and VBA event procedures can run automatically in response to user actions. In many cases, even non-technical Access users can create useful code by running Access wizards or by copying and pasting from the many examples available in books, magazines, and online forums.

The primary application programming interface (API) for working with the Microsoft Jet database engine from code is Data Access Object (DAO). In Office Access 2007, new objects, properties, and methods will be added to DAO to support the new features in the Access database engine. For example, multi-valued fields created using the new Lookup Wizard will be accessible from code as DAO recordsets.

In Office Access 2007, programmers will also have the option of enhancing their Access applications with add-ins and smart panes based on managed Microsoft .NET code. A primary interop assembly (PIA) for Access, as well as one for DAO, will enable managed code running in these add-ins and smart panes to manipulate Access user interface objects and Access data.

Office Access as a Developer Tool

Access is most notable in how it enables information workers to build applications that otherwise would require a professional developer. However, Access is also used by many professional developers, including many who are also trained to use more advanced programming tools, such as Visual Studio. These developers, and their clients, have found that for many database applications, Access can get the job done faster and therefore less expensively, while fully meeting the requirements.

Access is not suitable for every task. For example, Access provides only very limited tools for building Web applications. Also, Access does not easily support the development of multi-tiered or service-oriented application architectures composed of loosely coupled components, or applications that need to be built and maintained by large teams of programmers. The typical Access application is created by a single developer and is architected as a relatively monolithic solution that intermixes user interfaces, business logic, and data access. Applications that must support large populations of users, or that require very high levels of reliability or security are usually not good candidates for development in Access. However a very large number of business applications do not have these requirements.

Case Study: Developing Applications Quickly with Microsoft Office Access

John Brennecke is Senior Project Manager in the Customer Service and Distribution department of a biotechnology company with over 8,000 employees. Brennecke’s department is responsible for monitoring corporate and customer inventories to ensure that patients have an uninterrupted supply of the company’s products. Brennecke described why the developers in his department often turn to Access:

“Access is used for projects with little or no budget—‘drive-by’ projects that can be developed by one person in no more than a few weeks. These smaller projects are able to be approved by lower- or mid-level managers without the usual lengthy approval process. We can respond to requests for quick-turnaround reporting or process-monitoring. Usually with minimal red-tape and no extensive design phase.”

Brennecke’s department uses Access to link to the company’s Oracle data warehouse and to Electronic Data Interchange (EDI) data received from customers. Using VBA, staff members also import data from external sources that are exposed over Web services. In addition, Brennecke values the ability of Access to exchange data with other Office applications. The department often uses Access applications to export data to Excel to create charts for executives. Department members can also automatically create e-mail messages in the Microsoft Office Outlook® messaging and collaboration client that are sent to customers.

When asked how the role of Access at his company has evolved, Brennecke reports, “Access has become more popular in recent years. Everyone is realizing how fast application development can occur with Access and how cleanly the finished app performs. Other departments are beginning to take notice and are asking to hire Access consultants for their projects.”

Microsoft Office Access and Enterprise IT

Case Study: Streamlining Application Development

Peter Mullen is Manager of Application Development in the corporate services department of a Fortune 500 insurance company with almost 50,000 employees and over 500 offices in 120 countries. Following a major acquisition, the company undertook a reorganization that involved centralizing its data management. Mullen, who had some experience working with Microsoft Office Access, started exploring the ways that Access database applications were being deployed across the enterprise. He was stunned to learn how pervasively Access was being used. Mullen says, “Access was all over the place doing so many things that it blew my mind. Once I became known as ‘The Access Guy’ there were people all over the company who wanted my time.”

Not surprisingly, the quality of the Access applications Mullen discovered was quite variable. To Mullen’s trained eye, some were in fact very poorly designed, and yet they were getting the job done. Mullen also found positions hidden in the payroll in the field that consisted essentially of supporting a small number of departmental Access applications.

Mullen and his manager put together a presentation for the Chief Information Officer (CIO), proposing that the IT department begin formally supporting Access development at the company. They outlined a strategy for centralizing and rationalizing management of the Access applications that were evolving under the radar of their traditional portfolio management. The CIO saw the value in this proposal right away, and Mullen became the lead developer of a new group that was formed for this purpose. Mullen’s group created and nurtured the use of naming standards, coding standards, and standard methodologies. They also were able to reduce headcount in the field as support activities were centralized.

Mullen reports that after about two years, “We had standard code; we had about 200 applications, and we were handling it. We started to rationalize our portfolio and really started to communicate exactly what we were doing to IT. This was the key point¾that a lot of people in the organization started to see what we were really about. These were complicated problems being solved without spending a lot of money.” As more people in the IT organization learned of the success of Mullen’s group, he began to receive requests for “bolt-on applications, small department tracking projects, and proofs of concept. We hit a few of these and we had a real perceived value to the organization.”

Mullen summarizes what he’s learned about the optimal role of Access in the enterprise as follows:

“Access development in corporate organizations is simply a reality. People in the business are constantly looking for ways to add value to their customers and to free up their staff from mundane chores using automation that is inexpensive and easily accomplished. This is the strength of Access. The problem, from an IT perspective, is that the business comes to depend on products created without any IT involvement. Someone—usually an outsider or a low-level employee—becomes vital to the support of the product. So the question for IT becomes, ‘Will we provide support for this process?’ In my experience, providing an organized group that can create and support Access applications is a solid investment. It adds real and perceived value to the business and prevents a whole portfolio of applications from being developed under the radar of IT.”

Mullen continues, “IT usually looks at all of the Access applications that are developed in the field as problems to be eliminated. I look at them and I see opportunity. Applications developed in the field are sometimes things that should never have been created; yet often they are products that are highly valued and fill a real need. By treating field applications (which most often means Access) with respect, and providing support and portfolio management, you can sometimes find patterns of demand in your organization and help drive real IT value back to the business.”

Mullen is now working with the Architecture Team in his organization to identify candidates for migration to SQL Server and .NET applications. Mullen says, “Much of our portfolio will remain in Access, but some will migrate. There will always be a need for those quick and inexpensive solutions. The important thing is to keep track of these applications. They are the fingertips of your IT organization.”

Market research by Microsoft indicates that fewer than 5 percent of all Access applications developed in large enterprises have requirements that justify moving the data from a Jet database to SQL Server, and fewer than 1 percent require migrating the forms, reports, and code to a .NET-based solution.

Access developers, administrators, and users now have a new toolkit to aid them in analyzing Access 97 databases for upgrade and conversion to Access 2003. Users can take advantage of the tools in the Access 2003 Conversion Toolkit to find and analyze databases in preparation for switching to Access 2003. For upgrading to the 2007 release, Microsoft plans to release the Microsoft Office Migration Planning Manager.

Figure 9. Access 2003 conversion toolkit

Case Study: Using Access to Manage the Small Databases of a Large Company

Dave Corbridge works as an Information Services Manager for an aerospace manufacturer with 14,000 employees. Corbridge reports, “About 10 years ago, we created an Access programming group within the IT department to help meet the needs of the company for small databases. As the needs grew, so did our little group until we had six people programming full time in Access. All of us came from the user community instead of from within IT. Our programs cover such things as keeping track of tickets sold for a company party, tracking the shelf life of various materials used in our processes, expense reporting, and printing acceptance tags for parts. Some of our applications incorporate other parts of the Office suite such as Word, Excel, or [Microsoft Office] PowerPoint®. A sister company that recently joined us has been using Access for several years to run queries and pull reports from accounting data stored in Oracle. We’ve considered moving away from Access to use .NET Windows Forms and SQL Server, but we have been slow to change because nothing has been able to compare with Access for quick development while providing a full-featured front end that is easy for our customers to use.”

Corbridge’s department has considered the argument that users should be discouraged from creating Access applications and should instead work with the IT department to get professionally developed solutions. Corbridge gives four reasons why his department has decided to stick with Access:

“First, we don’t have the manpower to do all of the small database work in the company. Many of these are one- or two-user databases. If the users can do it themselves, why tie up our limited resources?

“Second, there are only a few applications that outgrow the users’ abilities and need to be passed on to the IT department. These applications may not be normalized and the programming poorly done, but there still has been a lot of groundwork that we can take advantage of in moving the application to the next level. This is generally better than having to start with nothing.

“Third, when we need to bring additional people into the Access programming group, these people will probably come from our power users who have been using Access on their own. Allowing users to do the small stuff helps us ‘grow’ our future full-time Access programmers.

“And, fourth, if 97 percent of users’ databases fit a light and agile Access requirement, why tie up the big guns (our Java, .NET, and C programmers) to do these small jobs?”

Access 2007 and Windows SharePoint Services

With Access 2007, users can easily move data from a local database file to a server with Windows SharePoint Services, which the organization’s IT professionals can manage, secure, and back up according to the organization’s policies.

By running Office Access 2007 on a SharePoint site, users gain new data auditing capabilities.

Revision History

New functionality enables users to track records and see who created, edited, and deleted records. Users can also easily view when the information was modified.

(Click image to enlarge)

Figure 10. Office Access 2007 on a SharePoint site

Permission Setting

Using Windows SharePoint Services, users can manage who has access to data. Users can assign limited reading permissions or full editing rights.

Recycle Bin

Users can now recover data that was erroneously deleted thanks to the Recycle Bin feature in Windows SharePoint Services.

Office Access is a Strategic Microsoft Product

Microsoft believes strongly in the strategic importance of continued investment in Access and the Access database engine. Access addresses a class of users who would never use Visual Studio and developers who can help empower and support those users. The Access database engine, with its versatile ability to connect to multiple diverse data sources and its powerful client-side query processor, fills a need that is distinct from SQL Server and SQL Server Express. Also, as a tool for creating rich Windows-based forms and reports bound to Windows SharePoint Services data, Access can add significant value to the Web-based capabilities of Windows SharePoint Services. The Web services–based technology that Access uses to connect to Windows SharePoint Services is a promising harbinger of how Access will be able to add value to other emerging service-oriented data sources. For these reasons, Microsoft sees a bright future for Access and will continue to invest strongly in its continued growth.

To meet these new challenges, Microsoft Office has evolved from a suite of personal productivity products to a more comprehensive and integrated system of programs, servers, services, and solutions. Building on the familiar programs many people already know, the Microsoft Office system is a set of tools designed to work together to address a broad array of information worker problems. Microsoft is extending its commitment to ensure that individuals, their teams, and entire organizations can transform the full range of their data storage and data tracking into real business value.

Access 2007 Limits

Erik Rucker — Mon, 05 Jun 2006 17:01:00 GMT

This is a quick post to lay out the limits in Access 2007 and make a little clearer how the application works and how it scales. The first table below shows the limits of the database engine itself.

Access Database Limits
Access database (.mdb or .accdb) file size	2 gigabytes, including all objects in the database (data, forms, reports, indices, macros, modules, etc.)
Total number of concurrent users	255. Note that the practical limit will likely be lower than this based on database design.
Table Limits
Number of tables	This is governed by a limit on the number of objects in the database, which includes tables, forms, reports, queries, etc. The limit on DB objects is 32,768.
Table size	2 gigabytes, less the space needed for system objects
Number of characters in a table name	64
Number of characters in a field name	64
Number of fields in a table	255
Number of open tables	2048 Note that this includes internal tables opened by Access.
Number of characters in a text field	255
Number of characters in a memo field	65,535 when text is entered through the UI 1 gigabyte if text is entered programmatically
Size of an OLE Object field	1 gigabyte
Number of indexes on a table	32
Number of fields in an index or primary key	10
Number of characters in a validation rule	2048
Number of characters in a validation message	255
Number of characters in a record (excluding Memo and OLE Object fields) when the UnicodeCompression property is set to Yes.	4,000
Number of characters in a field property setting	255

In addition, Access applications themselves have a number of limits, including:

Access Database Limits
Number of objects in a database	32,768 Note that this includes tables, forms, reports, queries, macros, modules, indices, and internal objects used by Access.
Number of characters in an object name	64
Number of characters in a password	14
Number of characters in a user name or group name	20
Table Limits
Number of open tables	2048 Note that this includes linked tables as well as local ones, and that the number may be somewhat lower due to internal tables opened by Access.
Query Limits
Number of enforced relationships	32 per table, minus the number of indexes that are on the table for fields or combinations of fields that are not involved in relationships
Number of tables in a query	32
Number of fields in a recordset returned by a query	255
Maximum recordset size	1 gigabyte
Sort limit	255 characters in one or more fields
Number of levels of nested queries	50
Number of characters in a cell in the query design grid	1,024
Number of characters in a parameter in a parameterized query	255
Number of ANDs in a WHERE or HAVING clause	99
Number of characters in a SQL statement	Approx 64,000
Form & Report Limits
Number of characters in a label	2,048
Number of characters in a text box	65,535
Form or report width	22 inches (55.87cm)
Section height	22 inches (55.87cm)
Height of all sections, plus section headers in design view.	200 inches (508 cm) Note an actual report can be arbitrarily long once the data has expanded.
Number of levels of nested forms or reports	7
Number of fields or expressions that can be sorted or grouped in a report	10
Number of headers or footers in a report	1 report header / footer 1 page header / footer 10 section headers / footers
Number of printed pages in a report	65.535
Number of controls and sections added over the lifetime of a form / report	754
Number of characters in a SQL statement that serves as the Recordsource or Rowsource property of a form, report, or control.	32,750
Macro & VBA Limits
Number of actions in a macro	999
Number of characters in a condition	255
Number of characters in a comment	255
Number of characters in an Action Argument	255
Number of modules (includes forms and reports with the HasModule property set to True)	1,000

The next post will be on Report View, and cover sort, filter, and group functionality from that view.

Access 12's new data engine

Erik Rucker — Thu, 13 Oct 2005 19:24:00 GMT

In the first Access blog post, I noted that Access 12 has a new database engine, but one derived from and very similar to the old Jet engine. There were a bunch of questions & emails about what we did, why, and what it means, and it will take me more than one post to get through everything so please be patient. In this post, I’ll cover what how the database engine fits into Access and how the new is different from Jet. In future posts, I’ll talk about the Access data security model and other engine-level stuff.

Access differs from most other database authoring tools by storing everything in a single file. When an Access author creates a database, the data and all the UI to work with that data all live in the same “.MDB” file. This makes database installation very simple and enables end-users to work with Access databases in just the same way they use Excel spreadsheets or Word documents. The engine provides 3 things to Access: somewhere to put data, somewhere to put UI forms and reports (this is really just more data), and a query processor.

In past versions, Access has used the Microsoft Jet database engine for data storage and query processing. Jet is commonly thought of as being part of Access (or even as being “Access”) but in reality it is a Windows system component built by the SQL Server team. Jet is unique in Microsoft because it provides both a data storage mechanism with a heterogeneous query processor. This ability to run queries across a number of different data stores is a key reason people use Access, so it was super important for us to retain that ability going forward. The SQL team is de-investing in Jet, and telling developers to code against SQL Server Express, but as it lacks the heterogeneous query functionality we needed, Access stuck with Jet.

However, we needed to extend the Jet engine, so took a “private” copy of it, and have extended it for Office. This means Access 12 no longer uses the system Jet engine, but is tightly bound to its own version. The new version is fully backwards compatible with the old, so it will read & write files from earlier versions without any problems. And since Access now can update the engine, developers can be confident that their Access apps will continue to work in the future. Developers can still program against the Access engine, but since it isn’t part of the system any more, application users will need Access on their machines. Developers targeting users without Access can continue to use the Jet engine as they have for years or can move to SQL Server Express.

The primary feature we added to the new Access engine is support for “complex data”. Complex data really isn’t so complex – it is simply a join in relational terms, or a repeating region in XLM terms. What it brings to Access is full schema compatibility with Windows SharePoint Services lists. This allows us to take SharePoint list data offline and to provide rich-client UI for SharePoint using Access.

In the application, complex data usually shows up as the ability to select more than one value for a field. For example, imagine an Issues list with a column for “Assigned to:”. In a single table you could only assign an issue to one person, and Access would provide a simple bound drop down list of people to Assign to. With Complex data, you can (still looking at a single table) assign the issue to several people at the same time, and Access provides a drop down check list with the ability to select several people. This works just the same way as it does in SharePoint.

Behind the scenes, Access does just the same thing a developer would when building the same functionality. We create a table for the join information and create a many-to-many join (in this example between issues and people). The Access database is fully normalized, and there’s no string manipulation monkey business or anything untoward going on – its just vanilla relational joins. However, from the end-user’s point of view, it is far simpler than building the tables and setting up the relationships herself. And since SharePoint doesn’t support joins, it maps directly with the SharePoint way of doing the same thing.

Developers, of course, are quite comfortable doing this by hand and can choose to either continue as they have or to use the new functionality. For developers targeting SharePoint, it provides a mechanism for handling SharePoint’s complex data structures naturally.

In the next post, I’ll talk about the changes to the Access security model, and how that flows through both the data layer and the rest of the application.

Microsoft Access Team Blog : Engine

Beginners guide to ODBC

Accessing external data using the IN clause

New Access 2007 Technical Article

Adding multiple attachments from a folder

Writing a Count(Distinct) Query in Access

Access Database Engine Redistributable

New, More Complete Access Overview

Executive Summary

Meeting the Varied Database Needs of an Organization

Broad Market Success

From Lists to Relational Databases

Microsoft Office Access, SQL Server, Visual Studio, and the .NET Framework

Case Study: Tracking Product Inspections with Microsoft Office Access

How Office Access Empowers Information Workers

Native and Linked Tables

Tables in Office Access 2007

Data Entry Forms

Reports

Queries

Macros

Modules

Office Access as a Developer Tool

Case Study: Developing Applications Quickly with Microsoft Office Access

Microsoft Office Access and Enterprise IT

Case Study: Streamlining Application Development

Case Study: Using Access to Manage the Small Databases of a Large Company

Access 2007 and Windows SharePoint Services

Revision History

Permission Setting

Recycle Bin

Office Access is a Strategic Microsoft Product

Access 2007 Limits

Next Post

Access 12's new data engine