Microsoft Access Team Blog : SharePoint

Publish to SharePoint (part 1)

Clint Covington — Mon, 23 Nov 2009 17:33:12 GMT

Today’s guest writer is Ric Lewis—the PM in charge of publishing to SharePoint.

A common question in the Access community is “how do I get my app on the web?” Here is the most recent example:

My wife and I have just started our own Recruitment business and I started an Access DB to basically be a contact manager and to track our jobs, candidates, clients and placements we make. I got to a certain point and realized I was out of my depth, so I enlisted the help of an Access Developer to finish it off. …

We currently work from home and are on a network so sharing the db is not a problem for just the 2 of us. In the new year, we plan to have 2 casuals start who are in different states from us, who we would like to be able to use the db as well.

From its inception, Access democratized data applications making it possible for non-developers to build client apps. Access 2010 is about to democratize data driven web apps. This means you can create a data application in Access 2010 client that can be published to a SharePoint server and used by other people who have only their web browser (no Access runtime or client required to use the app).

There are numerous implications of these new “Access Web databases” and I’ve no doubt we’ll discuss them in great length on this blog and in other forums. Today, I’d like to talk to you about the basics—the process of how you take an Access database to the web. Let’s start with the “Publish” operation.

You can watch Ryan and Clint’s demo on Channel 9 to see some of what we’re talking about in this post.

Web Objects and Client Objects

Any Access database is comprised of numerous objects, such as forms, reports, queries, macros and tables. In Access 2010, each of the objects in the database — with the exception of tables, which we’ll get to in a minute — has the additional designation of being a Web object or a client object. Let’s look at the differences:

Web Objects:

The overall goal of web objects is to provide a design environment that allows developers of applications to work effectively build objects that are both client and server compatible. Not everything you can do with the rich client can translate to the web. Here are come characteristics of Web objects:

Can only be created in Access 2010
Have a limited subset of full client object functionality.
Can be referenced by other web objects
Cannot reference client objects (unless you use IsClient—more about that later)
Are visible in the browser when the application is published
Are limited to expressions that are supported on the server

In the Navigation pane and Create ribbons, web objects are indicated by a small globe indicator on the icon:

Client Objects:

All existing objects in all ACCDBs made with Access 2007 and earlier
Can be created in Access 2010 for use in Access client
Encompass the full set of Access 2010 client functionality including VBA
Can reference web objects

Forms, reports, queries, and macros can all be either web or client objects. Objects cannot be converted from client to web type, nor from web to client. It is, however, possible to save a web object as a new client object.

To ensure data integrity after publish, a given database can only contain either web tables or client tables—not both. In Access 2010, a database that contains web tables is called a Web database. A database that contains client tables is generally called a Client database, or just a standard/traditional Access database. Both web and client databases are stored in the standard ACCDB format.

It’s worth pointing out that since web objects can only reference other web objects, it only makes sense to restrict web objects to a database that is composed strictly of web tables, a.k.a. a Web database.

It is possible to take an existing Access database and try to turn it into a Web database—we will cover that in a different blog post.

Design Web Objects

As we've covered, Web objects do not fully represent all the functionality of client objects. This is due to the fact that our server rendering is not yet as powerful as the full Access client.

Because of this, we have introduced a restricted design experience for Web objects. If you're working on a Web object, you will only see those options and design mechanisms which are valid for Web objects. On a high-level, this means the following:

Web tables do not support design view. These must be designed using the ribbon in the datasheet.
Web queries can’t be opened in SQL view—the query design view restricts the user to settings that are valid on the web.
Web forms and reports cannot be opened in design view and do not support absolute positioning.

To compensate for some of these changes, we've made additional design surface investments:

Datasheet ribbon design experience has been significantly expanded. All Web Table properties can now be accessed through the ribbon UI.
Form and report layout designers have expanded table layout tools, with property sheet and events showing all web-legal settings.
Macro designer for Web tables is filtered down to only expose those macros which will function correctly on the server.

To reiterate--client objects can take advantage of the new layout design experiences, but they also have the traditional design surfaces available (table design mode, form and report design view, etc.).

Publish

Once you’ve used Access 2010 to build your Web database, replete with Web forms, web queries, etc., you’ll want to publish that application to a SharePoint server to create an Access Web database.

Tip: Before you do this, you’ll likely want to set your default startup form in Access Options | Current Database).

To publish your application, you’ll need to enter the new Backstage.

You’ll notice the publish button at the top of your menu when you have a Web Database open.

Clicking publish will take you to the Save & Publish place. From there, you can fill in the server and application name for your published app:

Then simply click “Publish to Access Services” and you’re good to go. You’ll see a small progress dialog

And then a publish success dialog:

You’ll also notice that as part of publish, Access made a backup of your old ACCDB in the same place you had it saved before. This is your old pre-publish database, which you can use for a backup. It is not connected to your new web database. Here an app running in the client:

And the same app running in the browser:

In our next post we’ll talk about errors you may encounter during publish and how to maintain your new Access Web database. Enjoy your new Access Web database!

Synchronize with SharePoint under the hood

Clint Covington — Tue, 26 May 2009 18:46:00 GMT

Recently I was asked the following question:

I am looking to get an understanding of the internal operations during an Access 2007 synchronize execution. I have just been exposed to a SharePoint MOSS and Access 2007 environment where at times the normal sync time goes from 7-minutes to around an hour. I am taking the side of “network bandwidth” as the reason and not the side of “data quantity” as the root cause for the increased time.

Each user has their own copy of the SharePoint Lists (tables), which they work with offline. The users update their Access tables and at certain times (at their own discretion) during the day executes the synchronize function, which leads to why I expose myself to this forum's sages. Just what actions/decisions are being executed and how they are selected?

From a high level there are seven stages to synchronizing data with SharePoint:

The client sends pending changes to the server.
The client delete the local cache.
The client requests a new local cache from the server.
The server pulls the data out of SQL Server and sends it to the client in batches of XML.
The data travels the wire from the server to the client.
The client parses the XML and loads it into an in-memory table.
The client asks the user to resolve any potential conflicts.

Client Memory

When the user takes an application with SharePoint link tables Offline, Access stores an copy of all the list data in an XML format that mirrors what was retrieved from the server. When Access is running this data is parsed into an in-memory table. One of the first performance challenges you will face is when Access parses the XML and loads the data in memory. If the working set gets too big Access Windows swap memory out to disk which causes the machine to thrash. I typically check task manager to see how large the working set is. There are two remedies to this problem:

Increase memory on the client machine, and/or
Move data that doesn’t change (such as stale and large lookup data) to a local table.

Rehydrating the Cache

When the user clicks synchronize, Access will send pending changes to the server and request an updated version of the list. Access 2007 re-fetchs the linked list(s) including the User Information Lists. If your site has a large user information list—this could take quite a while. There are a couple solutions if your app has a large User Information List:

Move the data into it’s own site and not inherit the permissions from the parent site. This should give you a custom user information list that only includes people that are actually using the site.
If you don’t use the User Information List the link table can be deleted. The app should still continue to function other than not resolving the Created By and Modified By lookup fields.

The performance of fetching data is impacted by performance of the SharePoint Server to query the list items, return the user information list, and sending data down the wire. It is limited to the speed of light—the further you are from the server the slower the response. Obviously connection speed also has a huge influence. You also have to factor in parsing the XML and loading the DOM in memory.

What is on the wire?

You can see what is actually sent over the wire by installing the free Fiddler Web Debugging Proxy.

I find this tool invaluable to understand what is happening in the application.

In investigations that we’ve done, the pushing up and fetching of the data (which includes the network time plus whatever processing SharePoint does) often takes about 2/3 of the time in the go offline/sync scenario.

Conflict Detection

If there are conflicts detected during a sync operation (meaning the item was changed by someone on the server and someone on the client) Access launches the conflict detection dialog. We leave it up to the user to figure out which record to keep.

Summary

Access 2007 is much more efficient than Access 2003 working with SharePoint data; however, there are many opportunities for us to improve make this scenario for the client and server. We will talk more about this subject in a couple months.

Access Runtime support for SharePoint Offline

Clint Covington — Thu, 15 Jan 2009 08:51:11 GMT

The last few days I have pinged by several people asking about the SharePoint Offline functionality in the runtime. It seems like more and more people are starting to discover the new SharePoint link table and offline functionality. The short answer is—this isn’t supported. IOW - DoCmd.RunCommand acCmdToggleOffline is not intended to work in the runtime.

If you have a need for offline functionality then the users of your application must have a full version of Access. I heard of people rolling code to replicate offline functionality but it is a fair amount of work.

Sorry if this caused some confusion—we will get the docs updated.

Network World article - SharePoint taking business by storm

Clint Covington — Fri, 28 Mar 2008 07:57:22 GMT

There is a good article about SharePoint on Network World. Here are some of the more interesting quotes:

"Microsoft's SharePoint Server is on a billion dollar juggernaut to potentially become the next must-have technology, offering companies tools for building everything from collaborative applications to Internet sites..."

"Microsoft Office SharePoint Server (MOSS) 2007 is the fastest growing product in the company's history and seems to have as many uses as a Swiss Army knife. Its six focus areas are collaboration, portal, search, enterprise content management (ECM), business process management and business intelligence."

"In 2008, SharePoint has evolved into the prototypical Microsoft tool – good enough for small-to-midsize businesses, adaptable to large enterprises, and, most important, plenty of financial opportunities for third-party independent software vendors and systems integrators."

The article goes on to talk about the exploding growth, some of the current SharePoint weaknesses, and the looming battle with IBM. Interesting stuff...

From a personal perspective it has been rewarding to watch SharePoint grow up as a product. I can remember back in early 2002 when a small group of us invented the Web Part framework and the list web service APIs thus molding SharePoint into a developer platform. Interestingly, many of the key contributors of the first version of web parts went back to work on Access 2007 and are now working on Access vnext.

Interesting article on SharePoint adoption

Clint Covington — Sat, 12 Jan 2008 08:57:00 GMT

There is an interesting article on cmswire about SharePoint adoption and applications. Choice quotes include:

"The number of organizations that employ SharePoint for mission-critical applications is less than 20 percent, a figure expected to double over the next year. Meanwhile, the number of SharePoint applications will quadruple."

"...most deployments are hosted by third-party hosting providers. Organizations for the most part don’t have plans in place for hosting SharePoint applications."

In Access 2007 we made a big investment supporting SharePoint lists as link tables.

Access 2007 tips and tricks from the team

Clint Covington — Wed, 19 Dec 2007 07:14:00 GMT

Months ago I posted a three part tips and tricks series on Access 2007 on my personal blog. I recently got feedback that the series should be posted on the Access team blog--makes sense as this blog gets about 3 million more hits a month than my personal effort.

--------------

I have been working on a three part series of non-obvious tips and tricks for using Access 2007. The other series will be on designing forms and reports and my favorite keyboard shortcuts. I put together a rough draft of this series and sent it around to the Access team. Fortunately, many team members responded with some good additions.

Enjoy and have fun building great applications!

Clint

Navigation Pane

There is a hidden menu in the navigation pane that is quite useful. Right click on the navigation pane title for this menu:

My two favorite options in this menu is the Search Bar and the Sort | Custom Sort options. The search bar performs a Like *value* filter on the object name. This is really handy if you have a naming convention and want to quickly narrow down the displayed list. The Custom Sort option allows you to sort the objects in a custom order.

Another thing, if you have focus in the navigation pane CTRL F will automatically turn on the search bar. You can use the down arrow to select items and the enter key to open the object. It makes it pretty easy to find and open objects with the keyboard, especially if the object has a unique string in its name.

Don't miss this video tutorial to get up to speed quickly.

Open Last Database

Office Button | Access Options | Advanced Tab in the Advances section there’s a new option to have Access automatically open the last opened database on boot. –Scott (developer lead)

New Database Settings

It is possible to customize the default database settings for new databases. Our UA team and Allen Browne have nice write-ups about it—so I won’t repeat it.

http://office.microsoft.com/en-us/access/HA100378371033.aspx?pid=CH100948231033#blanktemplate

http://allenbrowne.com/ser-43.html#dbtemplate

Table and Field Templates

Table and field templates are quick ways to create tables and new fields with a number of property settings already set. The field templates have a number of core field types and fields taken from common schemas. It is possible to override and extend the fields in the field templates task pane and the tables that get created from the Create | Table menu.

The fields and tables are created based on the ACCFL files found in the drive:\Program Files\Microsoft Office\Templates\1033\Access directory. These files are XML files based on the same format if you exported a table as XML and XSD. Any schema files stored in the directory named ACCFL will show up in the fields task pane. Unfortunately, you can’t add additional tables or rename existing tables (painful cut). However, if you are always creating Order tables and never Issues—you might want to change Issues to Orders. Export your Orders table to XML/XSD. Rename the XSD to Issues. ACCFL and save it to the directory. Next time you create an Issues table it will be an Orders table.

Here is a link to a UA article on the subject.

New ADP

However, I frequently see questions about how to create a new ADP. It is a bit buried in the new getting started interface. For the users that need to create new ADP files, here are the steps:

1. Click on the new Database in the Getting Started screen.

2. Click on the folder icon next to the file path.

3. In the files of type choose Access Data Project.

4. Name the file and click Create

Here is a link to a UA article on New ADPs for more information.

Filtering and Queries

As a user interactions designer, I’m convinced context will continue to drive UI innovation. Contextual tabs in the ribbon are one example of some great work done in this space. Filtering is another place inside Access that being smart about context really improves the user experience. In the past, text in the context menu was Filter by Selection and Exclude Selection. Access 2007 I clarifies context through vocabulary. Selected next now shows up in the context menu to provide more clarity. Did you know that the right-click context filtering options change based on your selection? Give it a try—look at the right click menu when the first and last character is selected. Now try selecting the whole word. You will also notice the filter options change based on the data type.

The new filtering UI in Access makes it really easy to quickly create complicated WHERE clauses in queries. Save As for queries will flatten the active filter into the where clause. Open your favorite query and filter a date column using the This Month filter. Click on the Office Button | Save As. Give the new query a name.

Copy and Paste From Excel

Many good lists start in Excel and need to transfer into Access. Here is a simple way to get data into Access quickly.

1. Copy the data from Excel.

2. Create a new table inside Access

3. Click on the Add New Field

4. CRTL V – just like that you get a table inside Access. The new Table Tools contextual ribbon allows you to make the most common schema changes without flipping into design.

You should also notice the behavior of copy and paste from Excel to Access has been improved in other areas.

Import From Excel

When importing from Excel files you can now override the data-type for a field. Sorry, I missed setting the data-type on link. Hopefully, the Access team will do that feature in the next version.

Outlook Reminders for Saved Import and Export Operations

You might have noticed at the end of an import or export operation there is a victory dialog. There is an option asking you if you want to save the operation. You might notice at the bottom if you want to create an Outlook reminder.

This feature was designed for people that need to publish a report every couple days. You can use the Outlook reminders feature to remind the user to perform the task on a scheduled basis. The task has a Run Export/Import command that will repeat the recorded operation.

Here is a link to a good UA topic on the subject.

SharePoint Performance

The team spent a bunch of time improving SharePoint performance but it still is influenced by the speed of the connection to the server, server performance, and size of the data. I have found working with SharePoint data offline and using the synchronize command a far better experience. This works much faster unless you are working on data that everyone else is changing. The conflict resolver UI gives you the chance to override server changes or discard your own changes.

In the future, Access should provide the option for merge changes. Oh well, something for vnext.

SharePoint also has a flag called Cache List Data. This stores a copy of the list data in the database file. When the database opens the Access database engine only requests changes from the server. It is a nice performance win for the client and server.

One last thing… If your list on SharePoint is getting really large—you might consider linking to a view and not the list. This works well for scenarios where you have archived data in a table that isn’t necessary for your view. There is a trick—you can’t bind to the view using the UI. Use the TransferSharePointList method to create the link table. It has a property for the view.

Templates

You just created the projects template and think,

“Wow, MS did a pretty good job designing this template. I would really use it if only they had named the tables and fields something different (Projects should be called tblSpecs for my purpose).”

Name fix-up is helpful at renaming objects and field names in templates. I know, I know—-name fix-up has a terrible reputation. In this release we made a significant investment in the name fix-up code base. Why? Early on we made the decision to use name fix-up to create localized templates. Every template we ship has an internal structure of English names. When a localized template is instantiated Access uses the name map to rename all objects from their English name to the localized name.

What does this mean to you instantiating a template? It means that if you instantiate the projects template and rename projects to specs, name fix-up will make sure all references to the project table gets fix-up to specs. Access 2007 fix-up references in embedded macros, labels on field names, and conditional formats. The code was extremely well tested because if name fix-up failed a localized template would be broken. This commitment to use name fix-up dramatically increased the amount of testing and overall reliability of the feature.

Zac’s book on templates The Rational Guide To Microsoft Office Access 2007 Templates is the definitive guide. If you are thinking about building a template—this is the book to get.

Template Internals

Want to see what’s inside a template file, the gory details of what makes up the .accdt file format? Just rename the package to .zip and double click to open. Inside you’ll find all the different parts of the database represented in XML and TXT formats, along with resources like the picture Access displays on the template’s tile in Getting Started. (Zac—form and report program manager)

Interesting presentations about Access 2007

Clint Covington — Tue, 11 Dec 2007 08:44:00 GMT

Our friends in the UK Access User Group always put on a great national Seminar. It looks like the sessions this year were packed with helpful content and insight from developers. I found the following decks interesting:

Working with Access 2007 and SharePoint Services
presented by Derek Goodridge, WorkerThread Limited
Access 2007 Is Great – No It Isn’t – Yes It Is – No It Isn’t
presented by Alan Cossey
Access 2007 Runtime
presented by Ken V Smith

Props to Derek for his overview of SharePoint--lots of great information. There was one tip not covered in the talk that might be interesting for SharePoint users. Late in the cycle we added a feature called Cache List Data (it isn't documented very well) that improves SharePoint performance. You turn on Cached mode via the External Data | SharePoint Lists | Cache List Data. When the item is selected Access will cache all list data locally in the ACCDB. When a user closes the database an XML blob of data is stored in the database. When the user re-opens the database we hydrate the XML data and ask the server for items that have changed. The end result is significant client and server performance wins for large datasets. Something to consider if you are working with larger datasets against SharePoint.

Once again, enjoy the decks from the user group they are worth the download time.

Integrating Access Contacts with SharePoint and Outlook

Zac Woodall — Tue, 28 Aug 2007 19:10:00 GMT

There was a question on our post about getting Access to recognize tables as specific WSS table templates around what else you need to do to get the new Add From Outlook feature to work on a custom contacts table. This feature uses the same mechanism to determine that a table is a contact table, but more than that it needs to know how to map fields in your table to those in the Outlook contact store. There are a bunch of fields, so easier than building this out yourself, here's a quick snippet of VBA that will take any table, and make it into a contacts table. Just plop this into your solution, then update the table name and field names to reflect the fields in your custom contacts implementation, and run it.

' -----------------------------------------------
' READ THIS
' Make edits to the string values in the
' MakeContacts Sub below to match up
' with your table and field names.
'
' You shouldn't need to change the rest of
' this code.
' -----------------------------------------------


' CI is for ContactInfo
Enum CI

First
Last
Email
Company
JobTitle
WorkPhone
HomePhone
CellPhone
WorkFax
WorkAddress
WorkCity
WorkState
WorkZip
WorkCountry
WebPage
Comments
End Enum


' Each field map item maps between a field
' name in the Access table and a property
' name Access maps to Outlook and SharePoint
' contact field info.
Type FieldMap

prop As String
Field As String
End Type

' This Varible lists all the proeprties that
' can be mapped to Contact info. You fill
' it with the corresponding field names from
' your table.
Dim Map(CI.Comments) As FieldMap

Public Sub MakeContacts()


Dim strTable As String
Dim fm As FieldMap
Dim td As TableDef
Dim db As Database


' -----------------------------------------------
' UPDATE THESE STRINGS
' to match the table and field names in
' your app. It is okay not to set some if you
' don't have an equivalent.

' Set this to your table name
strTable = "Table1"

' Set these to your field names
Map(CI.First).Field = "First"
Map(CI.Last).Field = "Last"
Map(CI.Email).Field = "Email"
Map(CI.Company).Field = "Org"
Map(CI.JobTitle).Field = "Job"
Map(CI.WorkPhone).Field = "Work"
Map(CI.HomePhone).Field = "Home"
Map(CI.CellPhone).Field = "Cell"
Map(CI.WorkFax).Field = "Fax"
Map(CI.WorkAddress).Field = "Addr"
Map(CI.WorkCity).Field = "City"
Map(CI.WorkState).Field = "State"
Map(CI.WorkZip).Field = "Zip"
Map(CI.WorkCountry).Field = "Country"
Map(CI.WebPage).Field = "WWW"
Map(CI.Comments).Field = "Notes"

' END OF STRINGS TO UPDATE
' -----------------------------------------------


' This the code to mark fields in
' your local table with the correct
' Outlook and SharePoint field names.
'
' You shouldn't need to change this.
SetupContactProps
Set db = CurrentDb
Set td = db.TableDefs(strTable)

' Set the table level property that tells Access
' this is a Contact table.
SetProp td, "WSSTemplateID", dbInteger, 105

' For each mapped field, set the correct
' contacts property.
For i = 0 To CI.Comments

fm = Map(i)
If Len(fm.Field) > 0 Then

SetProp td.Fields(fm.Field), "WSSFieldID", dbText, fm.prop
End If
Next


End Sub

' This code initializes the contact property
' names that Access uses to map contact info
' to SharePoint or Outlook.
'
' You shouldn't need to change this.
Sub SetupContactProps()


Map(CI.First).prop = "FirstName"
Map(CI.Last).prop = "Title"
Map(CI.Email).prop = "Email"
Map(CI.Company).prop = "Company"
Map(CI.JobTitle).prop = "JobTitle"
Map(CI.WorkPhone).prop = "WorkPhone"
Map(CI.HomePhone).prop = "HomePhone"
Map(CI.CellPhone).prop = "CellPhone"
Map(CI.WorkFax).prop = "WorkFax"
Map(CI.WorkAddress).prop = "WorkAddress"
Map(CI.WorkCity).prop = "WorkCity"
Map(CI.WorkState).prop = "WorkState"
Map(CI.WorkZip).prop = "WorkZip"
Map(CI.WorkCountry).prop = "WorkCountry"
Map(CI.WebPage).prop = "WebPage"
Map(CI.Comments).prop = "Comments"

End Sub

' This is a helper routine which sets a property
' value first checking to see whether one already
' exists.
Sub SetProp(o As Object, strProp As String, dbType As DataTypeEnum, oValue As Variant)


Dim p As Property

On Error GoTo NotFound
Set p = o.Properties(strProp)
GoTo Found

NotFound:

Set p = CurrentDb.CreateProperty(strProp, dbType, oValue)
o.Properties.Append p

Found:

If p.Type = dbType Then

p.value = oValue
Else
o.Properties.Delete (strProp)

Set p = CurrentDb.CreateProperty(strProp, dbType, oValue)
End If

End Sub

Set SharePoint List Template for Access Table

Zac Woodall — Thu, 16 Aug 2007 21:32:00 GMT

There was an interesting question in one of the other posts that I thought I'd answer here to reach the broader audience:

Doug said:

If I export Northwind 2007 to WSS 3.0, the tables, like Customer, that contain 'Contact' type information get exported to an WSS 'Contact' content type. Very cool! Now you can view them in Outlook as a contact list.

However, if I craft a table from hand with the exact same name, and the exact same fields, and export it, it is exported as a 'Custom' content type and I get no Outlook love.

What magic is done in Northwind to make this happen? I really want to be able to do the same thing.

Great Question Doug!

The answer is that Access keeps around a jet property named WSSTemplateID which enables us to correlate which tables have a built-in SharePoint list template equivalent. Here's a list of IDs for the different types we support out of the box:

Contacts: 105
Events:106
Tasks: 107
Issues: 1100

Here's a line of code that will set the WSS ID for contacts onto a table, so that when you try to publish it, you'll get the Contacts template in SharePoint. Just replace Table1 with your table name, and you should be good!

CurrentDb.TableDefs("Table1").Properties.Append CurrentDb.CreateProperty("WSSTemplateID", dbInteger, "105", False)

Thanks for the awesome question!

SharePoint Apps Offline and Intro to SharePoint Designer

Erik Rucker — Fri, 13 Oct 2006 13:17:00 GMT

In the last post, I described how you can publish an Access database to SharePoint. This time, we'll look at taking that database back offline, making data changes while disconnected, and re-synching. I'll also briefly discuss updating the thin client version of the application using SharePoint Designer.

Opening the Application from SharePoint

When the database is published to SharePoint, it moves the data into WSS lists and the database front-end into a document library as described in the last post. Opening the app is as simple as going to the document library and double-clicking:

After double-clicking on the app, you'll be prompted to open read-only or for edit, and since we're making design changes, we'll choose edit.

This causes a local copy to be saved to your machine, so the SaveAs dialog is brought up and you can simply choose a location for the database.

(Click image to enlarge)

The database remembers where it came from in SharePoint, so it is easy to publish changes back to the server by clicking the "Publish to SharePoint Site" button.

(Click image to enlarge)

Working Offline

Taking the application offline, is available with one click from the External Data tab.

Since we've already saved a local copy, we're not prompted to do that again. When I click "Work Offline" the data from the web is brought down to the local Access file and cached in local tables. The links to the SharePoint tables are cut, but of course are remembered for resynch.

Now you're free to update the local data while offline, and the application behaves much like it did online.

(Click image to enlarge)

While the application is offline, of course other users may update data on SharePoint. They might do this through the browser or through the SharePoint web UI. Here they're using the Access Grid control:

(Click image to enlarge)

When you return to the network and want to resynchronize changes, it is again one click:

Now however, there are some data conflicts, so you're presented with conflict resolution UI.

(Click image to enlarge)

After resolving any data conflicts, the application is back online, and all changes are made directly against the linked tables.

Updating the Browser UI with SharePoint Designer

SharePoint Designer is a new product that makes it easy to design SharePoint web applications. You can use it to build a thin client that provides a similar experience to the Access thick client UI. The first step is to open the SharePoint site in SPD, then either start a new page or open one that you'd like to customize. In this case we'll customize the All Items view of the Issues list:

(Click image to enlarge)

Then we'll convert the view from a SharePoint List View to a "Data View", which allows extensive customization through XSLT. This is done from the right-click menu in SPD:

(Click image to enlarge)

Now the data view can be edited directly, and updating the columns and formatting is much like a grid view in Access:

(Click image to enlarge)

SPD has a data source task pane that is quite similar to the Add Existing Field taskpane in Access:

SharePoint Designer provides a rich set of tools for working with both the data and its presentation. It is based on web technologies, so writing code is quite different, but the general concept and much of the UI is very similar. For more information on SharePoint Designer, please see Alex Malek's blog and the Office SPD page.

Next Time

In the next post, I'll discuss building workflows in SharePoint Designer and using those in Access. After that, we'll move back to more Access client app developer focused topics.

Publish to SharePoint

Erik Rucker — Mon, 18 Sep 2006 19:18:00 GMT

In the last post, I gave a quick overview of SharePoint, SharePoint lists, and how Access works on SharePoint. In this version, I'll show what happens when you move an Access database to SharePoint.

Publish to SharePoint

Access has had a feature to "Upsize to SQL Server" for quite some time, and the "Move to SharePoint" feature in 2007 is very similar. It creates SharePoint lists for all the data, moves the data to those lists, and replaces the local tables in the database with remote tables linked to the newly created lists. The database behaves much like it did before, with some new functionality on the server, and potentially some client features no longer available. The move process is pretty simple, and starts from a local database to be moved. The picture below shows a nearly-final view of the Issues database from Access 2007 (with some sample data):

(Click image to enlarge)

To move the database, the user simply goes to the "External Data" tab, and selects "Move to SharePoint":

(Click image to enlarge)

This launches a simple wizard to move the database. The first step of the wizard allows the user to name a server to store the data:

(Click image to enlarge)

On the first step of the wizard, there's a checkbox for uploading the database to the server as well. Checking this box moves the database front-end, wth all the forms and reports, to the server. Then when other users need it, it is automatically deployed to their desktops. To do this, the user must choose where the file lives on the server, generally in a document library:

(Click image to enlarge)

Click OK to the SaveAs dialog after choosing a location for the file returns the user to the first pane of the wizard, with the file's location noted:

(Click image to enlarge)

Clicking the "Next" button on the wizard starts the move. Access creates new lists for all of the tables in the database, copies the records into them, and rebinds the forms and reports to the linked tables. In addition, it creates a link to the User Information table on SharePoint, and moves the front-end database to the Shared Documents folder specified above.

(Click image to enlarge)

When the upload process completes, Access presents a dialog noting that everything got moved up.

(Click image to enlarge)

Clicking on the checkbox (if it appears) will present a description of what got moved and a way to view a report of any application functionality that will change as a result of the move.

(Click image to enlarge)

After the application has been moved, it behaves much like it did before. Because the front-end is now shared, each user gets a separate copy and Access displays a message in the alert bar to help users who want to check-out and modify the shared front-end save changes back to the server.

(Click image to enlarge)

The navigation pane shows that the tables are now linked, and by selecting Properties from the right-click menu on a table, users can see where they're linked to:

(Click image to enlarge)

Users can also use the context menu to take invoke SharePoint actions on the linked table like opening the browser view, changing the columns and settings for the list, or setting up workflow.

(Click image to enlarge)

When the database is moved to the server, some functionality may be lost due to the differences between the SharePoint data store and Access. The Move to SharePoint feature creates a table in the database that lists any alerts and explains why they occur. The user can open this table from the Nav Pane:

(Click image to enlarge)

The Access Application in SharePoint

Once the application is on SharePoint, the user can look at the lists either through the SharePoint thin views or through the Access rich views. The Access tables now appear in the list of lists on SharePoint

(Click image to enlarge)

And opening one of those lists displays the data that was in Access:

(Click image to enlarge)

Since the data is now in SharePoint, it can use SharePoint functionality, so for example deleted items are moved to the Recycle Bin, users can apply workflow rules to the items, and changes to the list are versioned by default. You can change the settings for the default versioning below:

(Click image to enlarge)

The Access views appear in the list of views along with the browser views, so linking back to Access is as simple as selecting a view from the dropdown:

Clicking on "Open Issues by Category" will automatically bring down the front-end from the server and open that report in Access:

(Click image to enlarge)

Next Time

In the next post, I'll talk about taking SharePoint apps offline, and about making the browser version of the applications richer by using the new SharePoint Designer tool.

Windows SharePoint Services Overview

Erik Rucker — Thu, 24 Aug 2006 18:42:00 GMT

Up to this point, I've discussed building traditional Access client-side databases and run through some of the new tools and techniques that are available. This represents a very important part of the work done in Access 2007, but it is only one part. In addition, we've done a lot of work to make it easy to build client-server databases against Windows SharePoint Services. Doing this allows users who don't have the skills or privileges to be SQL Server DBAs to still get the manageability and stability benefits of storing data on the server, while retaining the ease of use of Access. This is a significant long-term bet for Access, and the level of server functionality can be expected to continue to grow in the future. I'll be describing Access 2007's SharePoint functionality over several posts, and will start with an overview of the server itself.

Windows SharePoint Services Overview

SharePoint is becoming increasingly well known, but is new to many Access developers. At the top level, it is simply a set of services that runs on top of Windows Server. It is shipped on the Office schedule, but it is included with Windows Server (i.e. if you have server, you can freely download the SharePoint bits). SharePoint provides the server cornerstone to the Office System, and SharePoint functionality appears throughout the Office client apps. SharePoint is designed to be a very horizontal technology, applicable to all Office users, and not limited to large organizations. We'd expect that eventually anyone with a file server, will eventually move to SharePoint, and those without servers will be able to take advantage of services like Office Live. There is an enterprise-focused SharePoint server, called SharePoint Portal Server, that runs on top of Windows SharePoint Services (WSS) and provides additional functionality to large organizations. Access 2007 runs on both, but with a few exceptions I'll call out, all of the functionality described below works on WSS and is included in the base version of Windows Server.

Windows SharePoint Services is described more fully here, but for our purposes, we can think of WSS as being composed of two parts: a platform, and a server application built on that platform. The platform contains things like an authorization model, a set of collaboration services, and flat file database (or "list") functionality this platform is highly programmable both directly and through web services, and in 2007 will have a dedicated design tool called SharePoint Designer. The application then builds UI on top of that platform to enable a collaboration app. This app is designed to enable team collaboration out of the box, and contains lists for things like a calendar, tasks, issues, and documents. User interact with SharePoint directly through the browser for adding or editing list items, uploading documents, or even modifying the site itself.

Here's a quick walkthrough of the parts of SharePoint that are most relevant to Access (there's a lot of other stuff we won't go through here, so if you're interested in SharePoint in general, please refer to the links above). Here's a picture of a demo SharePoint site:

(Click image to enlarge)

Clicking on the Announcements title, takes you to the default view on the Announcements lists, called the "All Items" view. If the all items view doesn't meet their needs, users can build their own custom views in the browser, choosing columns, column order, setting filters, and so on. The All Items view for our demo Announcements list looks like this:

(Click image to enlarge)

In addition to the default view, each list has a single-item view and a single-item edit form. The single item view looks like this:

(Click image to enlarge)

And the single item form looks like this:

(Click image to enlarge)

You'll notice above that SharePoint has support for rich text, complete with in-browser tools for formatting, as well as the ability to copy / paste from other apps.

Office 2007 users can also use the Access Datasheet to edit list items in the browser through a grid, which allows quicker editing for multiple items. The grid looks like this:

(Click image to enlarge)

Creating a new list is also done through the browser, and the user can select from a variety of built-in list types or create a custom list. The custom list creation UI looks like this:

(Click image to enlarge)

Adding columns is done after the shell of the list is created, through the "List Settings" UI, where you can choose data types, defaults, and so on:

(Click image to enlarge)

Each of the lists created shows up on the "List of Lists", which prevents orphaned content:

(Click image to enlarge)

In addition to the very basic list functionality described above, SharePoint provides a number of other features that help users. You can turn on version history for list items, allowing you to see who made each change and when, and roll back those changes if desired. In addition, deleted items land in a "Recycle Bin" and can be easily undeleted. Here's what the recycle bin looks like:

(Click image to enlarge)

Next Time

The SharePoint team collaboration app and SharePoint platform provide basic in-browser database functionality - there's a place to store data and simple forms and reports. Of course it lacks many of the things that make Access so powerful (relationships, remote data, logic) but it adds some things that are also useful to database authors (server manageability, recycle bin, versioning). In the next posts, we'll explore moving Access database to the SharePoint server and discuss building apps that take advantage of the best of the rich-client and the rich-server.

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.

Creating Schema

Erik Rucker — Tue, 14 Mar 2006 17:16:00 GMT

One of the most basic tasks in Access is creating somewhere to put data - designing schema. My goal for today was to run through the basic schema creation tools, and to leave the new "complex data" schema creation for next time, but in looking at the last post, much of the most basic ground was already covered, so we'll go further in this post and cover the complex data features as well.

Schema from Datasheet

As described in the last post, Access 12 can create schema by example, where the user simply starts typing into a grid (the "datasheet") and we guess the data types automatically and the product just works. This is simple for beginning users, and Access 12 does automatically create an ID column for each table, so there's a unique index for the table, and the user has something to build joins on as she gets more sophisticated. The basic schema by datasheet experience looks like this:

The user simply starts typing in the header row to set column names, then types data in the rows below to fill-in her table. Access guesses the data types as she does this. For more details, please look at the Starting From Scratch post.

Table Templates

One of the key problems that new users have in Access is creating well-structured databases. The tracking apps will help by creating normalized schemas for the most common applications, but many users will need to build their own databases without starting from the tracking apps. Table Templates provide a way for users to get well-structured single tables that they can easily add to their own applications. There's a simple entry point on the ribbon:

The entry provides a list of 5 basic common table types that the user can simply drop into her application and extend or use as is. An example would be the Issues table, which looks like this:

The full list of fields is easier to see in the table designer:

SharePoint List Templates

Access 12 provides a set of templates for SharePoint lists similar to that for local tables. This list is available from a button in the ribbon right next to the Table Templates:

It has a similar list of tables, with the exception of Custom (which creates a simple SharePoint list that you can then extend) and it also provides an alternate way to link to an existing SharePoint list. Selecting one of these lists brings up a prompt for the appropriate server and a name for the list:

The schemas for these lists are similar to those for the local tables, the only difference being that the SharePoint lists are created on the server and linked to Access.

Field Templates

Users who want to create their own tables can still get help building well-structured fields (i.e. with appropriate data types and lengths) from the Field Templates. Here the user selects the field templates button on the ribbon and gets a list of potential fields. This list contains a set of generic fields, and then all the individual fields from the Table Templates above. Click the image below to see the list of available fields for Issues.

(Click image to enlarge)

The user then simply drags and drops the appropriate field into her table.

(Click image to enlarge)

Lookup Fields and Complex Data

Access has supported "Lookup Fields" for several versions and has added power to the feature for Access 12 by allowing for multi-valued lookups. Lookup fields are simply fields that present a different value in their control than they store in the table. In the Issues example we've been using, "Assigned to" and "Opened by" are both lookups. The Issues table stores the ID of the entry in the Contacts table, but whenever the user sees the Issues table, she sees the Contact Name rather than the number. This is simply good database practice (normalized data, joined on unique identifiers), but made easy enough for non-developers. The last post showed creating a normal lookup column using the Lookup Wizard.

Access 12 extends the lookup concept by enabling multi-valued lookups. Where a lookup is really just a join made easy, a multi-valued lookup is simply a many-to-many join made easy. In XML terms this would be represented as an optional repeating value, which is why we think of this internally as support for complex data. SharePoint uses these data structures in a number of places (e.g. support for multiple attachments for each item in a list), so Access needed to add similar support to provide schema symmetry, but the concept is broadly useful outside the context of SharePoint. In our Issues example, the user may want to assign an issue to more than one person. This was do-able before, but required a lot of work (building the join table, setting up the relationships) and a lot of knowledge (i.e. how to build the join table, etc.). The Lookup Wizard now does all this for the user.

The user simply starts by clicking the Lookup Column button on the ribbon (with a column selected in the datasheet):

(Click image to enlarge)

Then she goes through the wizard as she did before:

(I skipped a couple of steps here, since they're the same as the ones shown before.) On the last pane of the wizard, she selects "Allow Multiple Values" and hits finish. This automatically builds (and hides) the join table and sets up the relationships, so the experience is just the same as for a standard lookup.

The key difference, though, is that the user can now select multiple people in the Assigned to column:

Next Time

The next post is a little up in the air. I'll hopefully be able to talk about the new Ribbon UI. However, we're doing some polish on how the UI is laid out and I'd like to be done before I explain how the whole thing works, so I don't then have to explain why it is all changed! We're pretty close to nailing that down, so hopefully next week I'll be able to describe it all. If not then, the week after. If I can't talk about the ribbon, I'll cover the new report designer, which is super cool too.

Tracking Application Overview

Erik Rucker — Mon, 06 Feb 2006 13:48:00 GMT

Access 12 and Windows SharePoint Services v.3 will enable out of the box “tracking applications” that can span the client and server or can run standalone on the client. A “tracking app” is a small data application that adds database functionality to the simple lists of data that many users keep in Excel today. These out of the box apps will give customers the broad reach of SharePoint online, and the rich client of Access. SharePoint will provide a set of simple building blocks that are useful on their own (e.g. the Issues list) and that can be combined into richer tracking applications using Access and potentially incorporating rich server-side components authored in SharePoint Designer.

Elements of a Tracking Application

Although in some sense, everything that someone might do with a database is a “tracking app”, we mean something much more specific. An Office 12 Tracking App consists of the following:

Simple components, assembled – the SharePoint team will provide a set of basic tracking lists that are useful on their own and may be combined into richer applications. The SharePoint building blocks all have similar schema at a high level, with something to be tracked (the “payload”) and several fields that track that payload (status, who it is assigned to, and when things are to happen to it). Access uses these basic lists as the building blocks of richer applications by combining them with one another and with new tables.
Template based – Office 12 tracking applications are created from a set of end-to-end solutions we ship in the box and on the web. These templates are usable with no modification and the goal is that many users will simply use the template without modification. The templates contain no code and so will run under medium security without issues.
Client / server data symmetry – both Access and SharePoint will ship similar templates with consistent schema for Assets, Contacts, Events, Issues, and Tasks. This allows the user to start from either place and create the same application.
Offline – regardless of where the user starts, she can take the SharePoint list data offline with a single click and can easily resynchronize the data when she returns. Access provides conflict resolution UI where necessary and any server-side business logic runs when the records are synched back up to the server.
Workflow provides business logic – the business logic for SharePoint tracking applications is driven by the WWF workflow engine in SharePoint. Tracking apps created in Access can use the Office DLC workflows, custom workflows from FrontPage, or even custom workflows authored in Visual Studio to drive their behavior.
Fully extensible – although we expect most users to be successful simply using the tracking app templates, the apps are completely customizable. Through our ease of use work in Access 12, we expect users to significantly extend the applications without ever writing a line of code.

Tracking App Examples

We're still working on the full list of applications that will be in the box, but the following is a representative sample:

Assets
Contacts
Events
Issues
Tasks
Customer Service
Projects
Marketing Projects
Sales Pipeline
Students
Faculty
Gradebook

The next post will look at the Issues tracking application in detail and we'll see how Access's new features are used in the applications. After that, we'll look at how the applications can be extended.