Access Services Work(s) II

I have now run this new Access Services application BOTH using a Terminal Services Session AND from my Native machine here in the Great Whote North connected using a VPN to the SharePoint Server in Seattle and the performance is exactly the same !!

Of course this is what you would expect considering that both are running with local caches and synchronizing with the SharePoint – Access Service Home site as necessary.  I can change records on either copy and see the results on the other.  But I now have actually SEEN it happen.   I guess I’m from Missouri – you gotta “Show Me”.

This is HUGE IMHO, stuff because it allows people me to create Access applications that can be used Worldwide by corporations with  distributed Offices.  Of course this is not for those million record databases. but I personally can imagine millions of potential Departmental or Group applications that could benefit from this immediately.  Who doesn’t know of an Access application that is starting to Wheeeze because it is being run using an MDB or ACCDW bacjend store across a WAN or even a LAN or that hasn’t been built because of that limitation ??

I believe this is a BIG deal and can’t wait to see SOMEBODY start to promote this to the world once the product ships…


About Biggus Dickus

Dick is a consultant in London, ON Canada who specializes in Microsoft Excel and Microsoft Office Development.
This entry was posted in Uncategorized and tagged , , , , , , . Bookmark the permalink.

2 Responses to Access Services Work(s) II

  1. Sam Elliott says:

    Hi Dick,

    Very inspired by your series of articles on the new Access 2010 with Sharepoint 2010!

    I have an application written in Access 2007 which I am attempting to port to Access 2010 and Sharepoint. It is split into a back-end database with the tables and a front-end user interface. Now I have no trouble moving the back-end data up onto my test account at Access Hosting. I had to do a few modifications to field names and lookups, but got around the obstacles in a couple of hours. Now my problem is the front-end. This contains a very large table of products from a supplier, around 124,000 records. I don’t want to put it up in the cloud because right now it runs at lightning speed locally. So my question is: how does this new hybrid paradigm cope with situations like this. I’ve been exploring the possibilities for a couple of days now, and just can’t work out how to do it. I currently distribute my application as an accde front end to the client computer, to protect my code base, and we multi-task using XPUnlimited and Remote Desktop. It’s a bit clunky, so I am very attracted to this new way of doing things, if I can fathom how it works with split databases.

    • Biggus Dickus says:

      I’m assuming that the “table of products” is read-only as far as you app ss concerned and gets refreshed every so often as the products change.

      If I am right then you COULD push that table up to SharePoint even though it is large for Access Services. If it is in fact read-ony and doesn’t change often then it would be pulled down to the local cache the first time the user opens the app after that tabe gets updated (which woud be surprisingly fast actually) and then it would just run formt the local version and the performance should be excellent.

      Otherwise an alternative would be to put that table in a separate Access ACCDB file out on your network and then attach it with a link to your frontend. This gets around the local table “shortcoming” (I really don’t think it’s a shortcoming just the way it is :-))..

      Hope this is what you’re looking for.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s