Using Sharepoint 2010 for data storage but still running full Access client with vba and normal forms
in [Help]
|
From: Bob Alston on 5 Dec 2009 23:40 Some time ago, Albert Kallah wrote that with Access 2010 it was possible to store access 2010 data on Sharepoint 2010 but still run the Access client in windows much as a "normal" access client, accessing the data on Sharepoint 2010. "Well, the rich VBA application can sit on your desktop, but the data sits on SharePoint. You can also have the application sit on SharePoint and a copy gets pulled down sure local machine when you click on and on the SharePoint site, you'll need access installed for this to occur. So, in this case we much talking about a 100% VBA application . " http://groups.google.ca/group/comp.databases.ms-access/msg/9cb8348d8fb6dfbd OK I am very interested in this approach as it allows maximum use of existing Access coding investment with the ability to share an app amount users physically separated. Previously you had to limit Access users to a LAN, or use terminal server or maybe even replication via the internet. This seems much slicker. Again my interest is data on sharepoint 2010 and use normal windows/ Access clients on each user's PC. I am not trying to take about the new web forms and reports which run in a browser. My question, is what do you have to do, if anything special, to have the application you published be available on the Sharepoint 2010 workspace so it can be pulled down to the desktop and run there? I just finished successfully publishing my test app to Sharepoint 2010 that I installed on my local PC. When I go to the workspace via the IE interface, I see all the database components - tables, queries, forms, reports, etc. What I do not see is any "overall" application that can be downloaded and run. What am I missing? Thanks Bob Alston
From: Albert D. Kallal on 6 Dec 2009 00:35 You even use SharePoint to pull down an application that is split. In other words, the data can reside on a backend accDB file sitting on a server, and the front end pulled down from SharePoint (but, this case, this means you suing a spit system, and that is NOT appropriate for wireless or a wan). Watch the following video. They go through all 3 possible: 1) 100% web 2) just sending the tables and data, but still rich front end (your case) 3) sending up a split database, and CONTINUING to use the standard back end, but the whole thing comes down from SharePoint... Managing Access Databases with SharePoint http://blogs.msdn.com/access/archive/2009/12/02/the-access-show-managing-access-databases-with-sharepoint.aspx Remember, we could upsize + send the tables to SharePoint in 2007, but the problem was performance, and also that we did not have any cascade relationships ability. So, for 2010, we have much better performance, and we have the ability for share to manage relationships. However, keep in mind the relationships and tables STILL MUST follow the restrictions for SharePoint lists (no compound keys, keep the PK as a autonumber id). -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 6 Dec 2009 00:37 You even use SharePoint to pull down an application that is split. In other words, the data can reside on a backend accDB file sitting on a server, and the front end pulled down from SharePoint (but, this case, this means you suing a spit system, and that is NOT appropriate for wireless or a wan). Watch the following video. They go through all 3 possible: 1) 100% web 2) just sending the tables and data, but still rich front end (your case) 3) sending up a split database, and CONTINUING to use the standard back end, but the whole thing comes down from SharePoint... Managing Access Databases with SharePoint http://blogs.msdn.com/access/archive/2009/12/02/the-access-show-managing-access-databases-with-sharepoint.aspx Remember, we could upsize + send the tables to SharePoint in 2007, but the problem was performance, and also that we did not have any cascade relationships ability. So, for 2010, we have much better performance, and we have the ability for share to manage relationships. However, keep in mind the relationships and tables STILL MUST follow the restrictions for SharePoint lists (no compound keys, keep the PK as a autonumber id). -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 6 Dec 2009 01:49 "Bob Alston" <bobalston9(a)yahoo.com> wrote in message news:1JHSm.38493$cX4.19748(a)newsfe10.iad... > It was under the link to edit the app. I opted to download the file named > <sharepoint workspace>.accdw > Yes, that extension is correct. It seems to open up and be run by the > Access 2010 client. > Yes. Remember, you can copy a pdf, a picture, word, excel or whatever to SharePoint. You can also copy a file like ms-access accDB file to the server. However, to establish "linked" copy of ms-access in which changes are auto synced up/down, you don't just up-load the file, you must publish the file. And, keep in mind since you have NO web parts, then there will be no web forms etc. on the SharePoint site. However, you STILL need to do this to setup the replication and auto upload (and auto download) of changes you make. Remember, you have to two options to sending up your local tables and linking them (they both are covered in that video). So, you can upsize the data to SharePoint. However, that will NOT give you the auto-updated front ends. You have to publish your application (but, since there no web forms, then you not see/have a web application). however, it is act of publishing that sets up the "replication" of your changes. So, now that you have the client downloaded, and you modify one form (say, edit some VBA in the form). when you sync your changes, then everyone else who downloaded a copy, when then launch the client application, then they will be informed there is changes to sync from the SharePoint system. when they sync, then your forms + code you changed will be sent down the write to their desktop. So, upsizing your tables is STILL different process then that publishing the database. So, if you just want to send up your tables and link them to SharePoint, use the external data tab. It will pump up all of your tables, and then setup links (this also the SAME process you have in access 2007 and SharePoint). As mentioned, this very much the same as using the upsizing tools (in that same tab on the ribbon) to up-size to sql server. when you do this, all that occurs here is moving of the tables up to SharePoint (or sql server) and then links are crated. However, to have changes you make to reports/forms/VBA code in a module, then you have to use the publishing option (available only in access 2010). So, publishing an application without any web parts is the same as upsizing + setting up the part that will auto update the front ends that everyone downloaded... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 6 Dec 2009 16:29
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:qoHSm.49392$ky1.44754(a)newsfe14.iad: > 1) 100% web > 2) just sending the tables and data, but still rich front end > (your case) 3) sending up a split database, and CONTINUING to use > the standard back end, but > the whole thing comes down from SharePoint... Is there the option to have your back end in SQL Server and use Sharepoint for nothing but distributing your app? I don't think the engine-level data integrity capabilities of Sharepoint 2010 are yet sufficient for a real application (the lack of compound indexes is a deal-breaker for me), so I'd be wary of moving the data storage to Sharepoint lists. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |