Can anyone point me to good books and articles or people to exchange
information with on the ins and outs etc of using Access 2010 and
sharepoint but from the perspective of using sharepoint only as the
central repository, sort of like the central replication hub, where all
users continue to run Access on their local PCs. These "hydrated"
versions of Access can run with an active connection to sharepoint or
run offline/disconnected. This allows the developer to continue to use
all the VBA stuff we have always used. Also all the forms and reports
and queries, etc continue as they have before Sharepoint.

It seems that such is a much better method of supporting geographically
distributed users of an app than trying to use replication across the
web ( I have never done this), more traditional replication (which I
have used very successfully with laptops and three host locations) or
terminal services.

The Access w/ Sharepoint as described above also has nice capabilities
for updating the logic in all versions of the software automatically
after changes to forms and reports - as long as the user is not
disconnected from Sharepoint.

I guess having the ability to have web based capabilities will be of
interest to some and maybe in the future I will find a client
requirement where that works best. for now, I am interested in using
Access and sharepoint as described above.

I have modified one of my own apps and successfully created a test
application as described above. My interest is now in learning more
about how best to do this and control/manage.

Hopefully there is someone else out there with interests similar to mine??

Bob

So:
Access:
2003 - tables over 5000 records, too slow, and no referential integrity
(no relational tables)

2003 - tables over 5000 records - much better, but still no relational
features. -- CORRECTION - I mean 2007

2010 - this is amazing. 5000 records - no problem, speed good and now
SharePoint has relational features.

On Jan 12, 2:40*am, "Albert D. Kallal" <PleaseNOOOsPAMmkal... (AT) msn (DOT) com>
wrote:
Hi Albert, this is unrelated to the subject at hand. I thought you
might find this link interesting. http://www.youtube.com/watch?v=HB_7R_-k_14

"Patrick Finucane" wrote in message
news:4b5d0cd3-e043-4d8e-8427-b68cc6adab1f (AT) q7g2000yqn (DOT) googlegroups.com...

Sure all that is being done here is that the InfoPath form is connecting to
a local database on YOUR computer.

That database has to be local, cannot be on the web, and cannot a mdb or
accdb file sitting on SharePoint.

When he says the database can be on the server, he means that you have some
server where you can have a path name.

This setup is zero difference then linking a access FE to the back end.

So the access data is local on your computer or at least on a folder that
you can link to from Access or InfoPath.
The restrictions of linking are sill the same for Access or InfoPath.

So the fact of launching it from the browser does not help the case that
much here.
So he is replacing the Access front end with InfoPath, but the back end data
has the same restrictions and issues.,

If you place access mdb file on a web server or even on SharePoint as a
file, you cannot link your Access front end to that data and nor will you be
able to link that InfoPath to that data file either.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com