A very interesting article.


http://dmoffat.wordpress.com/2009/11/06/access-2010-and-sharepoint-welcome-to-the-hybrid-access-application/

From what the author says, apparently beta users are now able to provide
information on details of Access 2010. If this is true hopefully more
info will become available soon. I hope so.

My key questions:

What limitations are there on what can be implemented on Sharepoint
services?

The author above says that there are some changes necessary to existing
apps, "an existing Access application cannot be Published to SharePoint
Server without a few changes. Indexes, relationships, lookups, primary
keys will all have to be changed".

Can you create an app using modules, macros and VBA event code in form
events?

Tell me more about how the local/client side app is created, refreshed and
runs (see article above).

My favorite feature about this whole web development model is that you're
using familiar access, and you don't need a database server and an server
side things set up to begin building the project. In other words your
development still occurs 100% client side, even for those web based forms.
You'll never have to play with HTML, and you'll never have to play with a
bunch of weird connection strings to some database server. In fact, it feels
like you're developing a local system.


.....

Great Input. Keep it coming.

Great Input. Keep it coming.

Are there other articles or documentation that you can now pass along,
perhaps things that were provided to you by Microsoft?

I got the idea that the new data triggors would work both in browser mode
as well as local mode. Can you clarify a bit?

Tell me more about the VBA limitations. I tend to have bits of vba code
on many of my forms to do specific things. Are you saying that none of
that runs in a browser-enabled form?

Are there other public sources of detailed information on Access 2010 and
the Access Services that you can point us to?

A
2007 list of limitations is outlined here:

http://office.microsoft.com/en-us/access/HA101314681033.aspx?pid=CH
101741461033

However with access 2010, a big portion of the above list
"limitations" is changed in a big way.

My favorite feature about this whole web development model is that
you're using familiar access, and you don't need a database server
and an server side things set up to begin building the project. In
other words your development still occurs 100% client side, even
for those web based forms. You'll never have to play with HTML,
and you'll never have to play with a bunch of weird connection
strings to some database server. In fact, it feels like you're
developing a local system.

The above process is really like a synchronization or send receive
process like when you're receiving email on a desktop client like
outlook. What's really cool about this is it also means that your
application can run in offline mode while you're running around,
then when you find a conneciton, then everything syncs up to your
sharepoint server - this supports a disconnected world very
nicely.

For the web side, Joe blow can run this. This is an 100% standard
**complient** browser application. I tested that appcaion using
ubuntu Linux + runnung FireFox and the results were perfect. There
is NO activeX, and NO silverlight downloads required of ANY kind
here. Even the hightling and shaded buttons workd 100% on the
linux box.

So, Mac, Linux, Windows, SmartPhone....All you need is a stadnard
complient browser here.

the
short answer is you have the full SharePoint security model here.
That security solves a TON of issues in terms of user Management.
You can certainly set user permissions on tables (SharePoint lists
- that means read, write, view, update etc). You can also of
course filter your web queries based on the user name. So, there
is a decent number of ways to manage these issues.

Thanks for all your helpful posts on this, Albert. I'm still not
convinced, but you're doing a great job of making it very, very
tempting.

Albert D. Kallal wrote:

so you can create your access app as normal if you indeed to do a mixed
Access client / Sharepoint backend?

Yes.

Once you complete your app as normal you "publish" to Sharepoint?

Yes. You still have to distinguish between an client application, and that

From then on you can use the local access app as usual, it will house the
data on sharepoint?

If another user wants to use (presumedly and is authorized at Sharepoint)
they can access Sharepoint and download or somehow get a copy of the
access front end?

Once they have the access front end, they also can use it as normal. All
their changes and your own (from the original copy of access) are
instantly updated on the sharepoint data master?

The new version of access has a new kind of form called "web forms"?

These web forms can run on your local access app just like traditional
forms do?

But these web forms can also run via a web browser alone?

Using web forms via a browser, the user needs not have a copy of MS Access
or any special software or operating system?

Are there similarly special kinds of web reports to run reports in the
web?

Someone mentioned (you) that if you use this approach to access a web only
app, that AJAX is used? If correct can you elaborate?

Also I read that some data is locally cached at the user's desktop? If
correct can you provide more on this?

Lastly, does the sharepoint referential integrity provide the equivalent
that we have been used to with Access itself?

It seems to me that Sharepoint adds more security/user role
management than you get with Access using ACCDB, and that bugs me a
helluva lot. It seems like a way to kill the ACE, since to architect
a real app, why not just skip ACCDB and use the Sharepoint data
store for your desktop app?

Am I missing something here?

In A2007 one could do Email data collection. Ask for the recipient to
fill out the email, send it back, and Outlook would feed the reply into
into A2007. But the email form was a bit clunky and I don't think it
permitted generic trapping of data entry. Has this feature been improved
in A2010?

However I'm not worried about jet go away, they just did a
humongous upgrade to it and gave it all those cool table triggers
and stuff. No doubt a good bunch of the bits and pieces they
changed are for all this new sharepoint replication....but on the
other hand even for longtime desktop developers we do now have
table levels triggers and procedures...

The data is attempting to synchronize
itself at all times. You can even break your internet connection
and keep working. However, for things like forms and reports if
you modify them, then there's place where you see a notification
that your changes have not been set up to the server. That same
notification box will also inform you that there's pending changes
that need to come down from the server. So, for these types of
changes you have to hit the sync button. Your also informed of
this changes being pending issue when you start access and an
application, and you also get information when your shutting down
access. And, you can see this info dialog in what we call
backstage at all times to inform you of this status.