Using Sharepoint 2010 for data storage but still running full Access client with vba and normal forms
in [Help]
|
From: Albert D. Kallal on 9 Dec 2009 02:25 "Daniel A. Galant" <daniel.galant(a)mindsharp.com> wrote in message news:OtUQ35FeKHA.4880(a)TK2MSFTNGP05.phx.gbl... > The front ends don't sync to anything, they pull data from a backend SQL > server. Actually, with SharePoint, they now do..... Right, but we not talking about the data here, we talking about syncing changes to the applications. Individual parts of the application (forms, reports, code) after being modified can thus be synced to the copy sitting on SharePoint. This is NOT the whole application being changed, but ONLY the parts that have been worked on. The above is based on the new features in ms-access in which you can "web" publish an access application to SharePoint. So, after you web published then if you modify a SINGLE form, or some code on the CLIENT side and then hit the sync button, those changes are then synced from the desktop client to the copy of the application sitting on the server. Any other user that decides to open the client application via SharePoint (thus does not yet have a copy of the application on their desktop) will then get a copy of the application downloaded to their desktop. And, after that occurs, again I can modify ONE form, and ONLY the one form is synced, NOT A WHOLE copy of the application. So, any one who has one of these copies on their desktop will receive NEW updates if a form is modified next time they launch the application. Now, the above is generally assume to be a web based application in ms-access. (just to get you up to speed, access 2010 allows 100% browser based (web) applications to be built using SharePoint 2010). However, since ms-access allows a mix of both VBA forms (non web), and also 100% web forms, the above automatic "replication" or "deployment" system CAN ALSO be used for 100% non web based applications. (but, to be clear, you actually are talking about a web based application with VBA forms in it). You can also upsize, or setup linked tables to SharePoint lists in ms-access, but that's not what we are talking about. So, that "published" application (the act of publishing has significant meaning here by the way) thus might not have any web components, and might not even have its data on SharePoint. However, that app can still have rich VBA forms that are based on tables linked to SharePoint, SQL server, or even a back end access on a file share. So, this discussion is talking about syncing the application parts, NOT the data part. The question being asked is while I am developing an application, what happens if I accidently sync out my ONE OF my VBA forms that was working on. If I DID NOT want to send out this form then how can I revert the application back to the previous version of the application..... That is our context of this discussion... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Daniel A. Galant on 9 Dec 2009 15:04 Fine, let's not forget where SharePoint is storing all this info, in SQL. What is happening here is that Access Services (a feature of 2010, so not currently available in this manner in SharePoint 2007) is taking the data of your Access database and converting it to SharePoint lists and forms, doing the behind the scenes work so you don't have to. The data is still stored in the backend SQL server, stored in the content database of the site collection where you publish your Access application. If your user then accesses that 'application' using Access, it will download the data and convert it back into the relevant Access database using a local copy (as you mention) and then push any changes back up into SharePoint. What this does is allows users to access the information either using Access or a web browser, since SharePoint is now handling the data management. All the normal SharePoint rules will still apply. Lists, items, libraries etc. The Access application simply becomes a set of these in a SharePoint site. If you publish an early or premature version of your application, SharePoint will create the lists, forms etc, for this app. Not having played with any of this yet, (Access is certainly not my forte) while there is supposed to be two way synchronization, I don't know that re-publishing an earlier version of the app will delete any lists or forms that would have been added by your premature push of a newer version of the application. I hope this is making some sense within the context of the thread. -- Daniel A. Galant Imagine what we could be... if we could just imagine. "Bob Alston" <bobalston9(a)yahoo.com> wrote in message news:eCBTm.45381$ZF3.12828(a)newsfe13.iad... > Daniel A. Galant wrote: >> Ok, I'll admit that I've been trying to follow a bit of this discussion >> and I'm completely lost here as to what you are trying to do. A >> SharePoint Front End server is simply the access point that a user >> connects to to then get at whatever data you are trying to make >> available. The front ends don't sync to anything, they pull data from a >> backend SQL server. How that data gets into SQL can be a number of ways. >> SharePoint can also be used to present data from other sources as well as >> SQL through web parts, connections etc. If I lose a SharePoint front end >> server from my farm, it's not a real big deal, as I can simply create a >> new one and it will pull the data it requires from the SQL server's >> configuration database for the farm and start working. (There is a little >> more to it than that, such as any customizations, host headers that may >> also need to be considered, but effectively it is just a matter of adding >> a server to the farm). >> >> As for moving data from dev to production, this is often done through the >> content management function of SharePoint whereby you link a site in the >> dev environment to one in the production and then publish data from one >> to the other. This is a one way operation. >> > There are a few subthreads of this overall thread. My original object was > and is to pursue using Access 2010 as a rich client front end to data that > is stored/hosted in Sharepoint. While it is possible to use SQL server > and other back ends, Microsoft is providing software to migrate the data > from Access to Sharepoint. Doing this allows an Access app to be shared > by geographically distributed Access users. Normally, an access database > is limited to LAN based sharing. > > Also interesting in this approach is that the Access front end, once > synced with Sharepoint, actually runs using a local cache of the data. It > then syncs/updates the data in Sharepoint in the background. > > These videos - posted previously - have a pretty good explanation. > > http://channel9.msdn.com/learn/courses/Office2010/OfficeServicesUnit/DevelopingWithAccessServices/ > > http://dmoffat.wordpress.com/ > > HTH > > bob
From: Daniel A. Galant on 9 Dec 2009 15:15 See inline... -- Daniel A. Galant Imagine what we could be... if we could just imagine. "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in message news:DhITm.85021$Xf2.78104(a)newsfe12.iad... > "Daniel A. Galant" <daniel.galant(a)mindsharp.com> wrote in message > news:OtUQ35FeKHA.4880(a)TK2MSFTNGP05.phx.gbl... > >> The front ends don't sync to anything, they pull data from a backend SQL >> server. > > Actually, with SharePoint, they now do..... > > Right, but we not talking about the data here, we talking about syncing > changes to the applications. > > Individual parts of the application (forms, reports, code) after being > modified can thus be synced to the copy sitting on SharePoint. This is NOT > the whole application being changed, but ONLY the parts that have been > worked on. > This is still data that is stored inside of SQL. Just as if I added a new column to a list or library. No argument. > The above is based on the new features in ms-access in which you can "web" > publish an access application to SharePoint. So, after you web published > then if you modify a SINGLE form, or some code on the CLIENT side and then > hit the sync button, those changes are then synced from the desktop client > to the copy of the application sitting on the server. Any other user that > decides to open the client application via SharePoint (thus does not yet > have a copy of the application on their desktop) will then get a copy of > the application downloaded to their desktop. And, after that occurs, again > I can modify ONE form, and ONLY the one form is synced, NOT A WHOLE copy > of the application. So, any one who has one of these copies on their > desktop will receive NEW updates if a form is modified next time they > launch the application. > > Now, the above is generally assume to be a web based application in > ms-access. (just to get you up to speed, access 2010 allows 100% browser > based (web) applications to be built using SharePoint 2010). > > However, since ms-access allows a mix of both VBA forms (non web), and > also 100% web forms, the above automatic "replication" or "deployment" > system CAN ALSO be used for 100% non web based applications. (but, to be > clear, you actually are talking about a web based application with VBA > forms in it). You can also upsize, or setup linked tables to SharePoint > lists in ms-access, but that's not what we are talking about. > You can't use VBA when creating an Access database that you are going to push up to SharePoint. VBA, Action Queries and traditional Access macros are not supported by Access Services. > So, that "published" application (the act of publishing has significant > meaning here by the way) thus might not have any web components, and might > not even have its data on SharePoint. However, that app can still have > rich VBA forms that are based on tables linked to SharePoint, SQL server, > or even a back end access on a file share. > > So, this discussion is talking about syncing the application parts, NOT > the data part. The question being asked is while I am developing an > application, what happens if I accidently sync out my ONE OF my VBA forms > that was working on. If I DID NOT want to send out this form then how can > I revert the application back to the previous version of the > application..... That is our context of this discussion... > > -- > Albert D. Kallal (Access MVP) > Edmonton, Alberta Canada > pleaseNOOSpamKallal(a)msn.com > >
From: David W. Fenton on 9 Dec 2009 16:45 "Daniel A. Galant" <daniel.galant(a)mindsharp.com> wrote in news:OtUQ35FeKHA.4880(a)TK2MSFTNGP05.phx.gbl: > A SharePoint Front > End server is simply the access point that a user connects to to > then get at whatever data you are trying to make available. True up to Access/Sharepoint 2010, which is the subject of this discussion. The new version offers new features, including the capability I've been quizzing Albert about. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 9 Dec 2009 16:47
"Daniel A. Galant" <daniel.galant(a)mindsharp.com> wrote in news:#AqAirQeKHA.3792(a)TK2MSFTNGP02.phx.gbl: > I hope this is making some sense within the context of the thread. Your comments are only partially applicable to the version of Sharepoint that this thread is discussing. That is, all the capabilities of previous versions of Sharepoint remain, but are vastly expanded with Access services. You might spend some time going back to the numerous threads about Access 2010 and Sharepoint 2010 in this newsgroup, mostly launched by valuable postings from Albert Kallal. Once you get caught up on the discussion, you'll regret what you've said here, as it's incorrect. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |