You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
Today’s guest writer is Ric Lewis—the PM in charge of publishing to SharePoint.
In our last post about publish, we covered the basics of how to publish your Access database to a SharePoint server. In this post, we’ll look at how to troubleshoot publish issues and maintain your published database.
When you try to publish, there are a few things that may go wrong. There are three places where you may be notified of these errors:
Access Services v1 does not support all the rich controls and properties that the Access client supports. While we’ve tweaked the designers to attempt to keep users from doing things that are not web legal, some issues may slip through. To prevent users from publishing things that are not supported by the server, we created a Web Compatibility Checker. This tool checks the web compatibility of the tables and web objects.
The Web Compatibility Checker acts as a gatekeeper, always checking before publish or import of objects to make sure that they are web-safe.
You can run the compat checker manually:
Or it will be run for you during sync/publish:
If your application is valid, but the publish operation failed while interacting with SharePoint, the errors will be logged in this table. Issues here include network issues, SharePoint errors, and exceptions from incorrectly formatted data. They are logged in the “Move to SharePoint Issues” table.
Publish is an asynchronous operation. The client sends all of its information to the server, and in most cases, the server continues to process the new application even after the client is done publishing. If there are issues in the server’s processing of your application, the errors will be listed in this table as they happen.
You can look for notifications from this log from the Backstage area:
So what’s happening when we publish a Web Database to a server to become an Access Web Application? Behind the scenes, the client outputs its web objects in standardized formats:
After publish, the server takes these objects and compiles them together into the series of web pages and data objects which comprise an Access Web Database.
Note: The format of web objects has been documented in the Access Application Transfer Protocol Structure Specification so that third parties can write additional tools on the platform.
At this point, the local ACCDB on your computer is a cached version of your database. Changes made in your ACCDB will be reflected as changes in the web application and visa versa. These changes fall into two categories: data/schema changes and object changes.
In your published database, all of your tables are linked SharePoint lists. Any data updates you make on the Access client or through the web browser change the server data immediately. When you make schema changes on the client, these schema changes are propagated immediately to the server.
Conflicting data changes will be exposed through the data conflict dialog present in Access 2007.
All the other objects in your database (forms, reports, queries, and macros) are only changed when you choose to sync. This means you can make a batch of changes and only apply those changes when you are ready to commit the entire set.
To send your changes to the server, you must use the “Sync All” button in the Backstage. This will pull down any new changes from the server and send local changes to the server.
If changes conflict with another user’s changes, Access will bring the most recent server changes down into your application, and create a copy of the conflicting object which contains your changes.
You’ll notice that you can see the user whose changes conflict with yours.
To get your changes on the server, delete the existing object and rename your copy to the original name, or you can try to merge your changes with the changes made by the other user by hand.
We welcome your feedback and questions.
Comments: (5) Collapse
Publishing to Sharepoint is an ideal solution for one of my clients. I have tried using the "Move to Sharepoint" command to an "Office Live Workspace" but get an error. The Workspace is clearly shown and I select a document library. The transfer of the first table is initiated but get an error "property not found" No error table is created with a further explanation. I guess the problem is something to do with "Office Live" not allowing Access databases. What do I need to do to enable this to happen? Do I need to install Sharepoint software on my local machine? I would be grateful for some help here. Yours sincerely, Alan Brown
Software Developer
Thanks very much for this explanation. It helped me understand the process better and what I was hoping for. The next question is: can the ASPX forms be taken, modified and used in a regular browser window? Be a fun experiment. I don't access to Sharepoint but totally want to experiment with it.
Is it possible to publish an Accde file or only Accdb?
Thanks
Gilad
Alan Brown,
Office Live is not yet on Sharepoint 2010 so I wouldn't think this will work and I am not sure it ever will be the correct edition of Sharepoint 2010. Mind you you can publish tables from Access 2010 to Office Live and you can take such data offline using the Access 2010 runtime beta, which you can't do using Access 2007 runtime. You get some strange error messages, but it does work. Apparently the erroneous error messages are being sorted out. Alan Cossey
I've just had an awful time the last couple of days trying to get SharePoint Server installed so I can work with the "publish to SharePoint" feature working. Microsoft has released SharePoint 2010 Server as public beta, so it should be possible to install the beta locally and use the public Office 2010 beta against it. (In theory, at least) The SharePoint 2010 beta installation is no fun. The hardware requirements are stringent: 64-bit server OS (Windows 2008 Server R2), lots of memory (I'm using 8 gigs), etc. Yes, I know there's workaround to install on 64-bit Windows 7, but I'd like to use a real server OS for my testing. It's not Office's fault, but the manadorty SharePoint configuration step fails over and over again on step 8 (creating sample data). I'm not sure whether the SP config failure has anything to do with the problem I'm seeing when trying to publish bound Access forms to SharePoint. I can get tables and unbound objects published without error. They work beautifully in SharePoint. I can make changes to database objects at the Access client and re-sync them with SharePoint, and I can even publish bound forms to SharePoint. But, the bound forms constantly throw errors and fail to render in SharePoint. The error reporting in SharePoint is abysmal -- there's nothing to indicate what's throwing the errors. I don't think it's an issue on the Access side at all. The Access tools work exactly as Ric documents (thanks Ric!), but things aren't working at the SharePoint side. I'd be interested in hearing from other people who've successfuly published Access apps to SharePoint. This is a very valuable capability, and I'd hate to see it earn a bad reputation out of the gate. I'm hoping my experience is singular and uncommon. I haven't been able to find any other reports where people have either succeeded or failed when publishing Access apps in a home-brewed SharePoint environment. It'd seem a small-scale installation like mine is a good prototype of how publishing Access apps to SharePoint will be done in the future. Thanks! Any suggestions are greatly appreciated.
Comments: (loading) Collapse