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.
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.
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.
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.
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:
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.
After resolving any data conflicts, the application is back online, and all changes are made directly against the linked tables.
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:
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:
Now the data view can be edited directly, and updating the columns and formatting is much like a grid view in Access:
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.
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.
If you look over blogs for other Office products, you never see this level of negative comments about the new version. Only with Access. The comments from hard-core Access developers are almost universally negative. Most of the positive developer comments are from the few mercenaries who write for Access journals and newsletters (i.e. for money or fame), or from those who never use SQL Server. Gee, I wonder why that might be???? Let's not forget about the fantastic improvements to conditional formatting that are appearing in Excel, but were not deemed important enough for Access! For years, we have complained about conditional formatting, so the Access team gives us Sharepoint, as a reward for our loyalty. Yes I am happy about the new features. Unfortunately, many of them do not make it into ADPs. I am grateful for the continued support of ADPs, but I expected to see much more. In particular, I expected the Access team to follow Microsoft's own published best practices, and promote integrated security with application roles. Thus, at present we have no built-in security model other than "role your own." I understand that they felt compelled to include ribbons for Office consistency, but honestly, if they had dropped the Sharepoint juggernaut (aka replication for idiots), they probably would have had enough time and resources to address almost all of our concerns. I've been around for VB 1.0 and Access 1.0 - This is just as bad as the Access 95 fiasco, where they first broke everything before fixing it over the next 2 releases. They really need to delay this release until they get it right.
There is no chance of delaying the release. Basically what you see in the Beta 2 technical refresh is what you are going to get. As Clint mentioned earlier, "Access 2007 is pretty much done". I just wonder if any of this feedback is getting back anyone other than Clint and Erik. Does anyone else at the mighty Microsoft care? Apparently not....
I won't give up Access as a great development tool because of the reasons that is posted from disappointed developers in this blog. I have been working with Access since 1994, mostly with ADP's the last years, and it's a really nice combination of RAD and a stable data´base environment. I don't understand all of the barking and jelling of what is missing in the new version, maybe it's not so much improvements for developers but I really looking forward to get a modernized look to my apps that were created for 5 to 15 years ago. And an enhanced reporting tool is also welcome, that too will bring more value out of my customers running applications. I like Access and I'm looking forward to start learning about new features in Access 2007. Benka
Has anyone taken a look at Microsoft OFFICE Accouting 2007 at www.OAisbetter.com? This is not Microsoft Money, not Microsoft Great Plains, not Microsoft Navision. This is a product branded as Microsoft Office complete with the familiar muti-color frame logo. Microsoft has spared this spanking new application from the "ribbon/no menus for you" design foisted upon Access 2007 developers. How can they justify this inconsistency? How can they proclaim that users will find the ribbon experience superior to conventional menu structures and then not implement the ribbon in this NEW application, written to complete against Quickbooks and Peachtree? If their own developers reject the ribbon nonsense for application development under the "Office" moniker, why do they insist on sticking it to Access 2007?
But the website says it (OA2007) has: "a familiar and consistent user interface that works with and looks like other Microsoft Office programs." Hmmm....
...and Infopath 2007 does not have the Ribbon
Visio 2007 does not have the Ribbon
Outlook 2007 kinda has the Ribbon but, to be honest, I kinda like the ribbon...well just a little. It really irritates me that they did not bother to include it with Infopath or Visio. To me that says "RUSH JOB".
And besides Infopath, Visio and Outlook, also mysteriously lacking the Ribbon: OneNote
Sharepoint Designer So the wonderful Ribbon is somehow not included in all of these apps (7 out of 11 Office 2007) , but is forced upon us in Access. Unbelievable!
Geez, if they left the ribbon out of Access 2007, you would complain about that too. All we really want is to keep the old stuff available, as a developer choice, and to preserve our investment in "legacy" (i.e. this year's) code. Running at 1280 x 1024, the ribbon looks just fine :-)
I have an appplication that reads information from Access Database, it uses ADO (msado15.dll) to open a database using Connection15::Open( ). I am unable to open Access 2007 database using this method. I get the following error: "Microsoft JET Database Engine, Unrecognized database format". Is there something I am doing wrong or I should be aware of? Does msado15.dll support Access 2007 databases? Thank you in advance.
Erik / Clint Is this blog still active? I was hoping for some more posts from you guys...
This is a former cynic here. When I first saw what was going on with Access 2007, I was not particularly impressed. However, the more I look at it and see things like much better security (even if you have to jump through hoops to use it effectively) and Sharepoint integration, the more I am impressed. I have just started playing with Office Live and am mega impressed with how it works with Access and Outlook (haven't tried it with Excel yet). I was in no hurry to get involved with Sharepoint, but it has loads to offer.
Depressing reading for anyone with real users, relational data and an interest in moving towards browser/web deployment without the hassle of deploying or hosting SQL server. Plugging these apps into SharePoint would be wonderful if it was going to work If you have a relational database structure and want to share it, with synchonisation/replication, and web access, and use Access as a development tool, what are MS suggesting as the approach? It would be great if you could deploy an Access relational database structure to Sharepoint with confidence, build Sharepoint forms for simple tasks, and have reliable replication back to the core app sitting in say a small office. Similarly, th eother apps liek Groove look interesting but don't seem likely to help database developers. No-one has talked of Access 2007 front ending SQLExpress - is it a viable option? Where is the MS road map for the next few years? How do Jet, Access, the MSSQL variants and Sharepoint fit together?
I see in your strategy document you say 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. I thought DAO was deprecated and ADO was the preferred technology to use. Please explain when you are saying each should be used. Thanks