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,
Windows 7 Keygen, 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! <div