Using Sharepoint 2010 for data storage but still running full Access client with vba and normal forms
in [Help]
|
From: David W. Fenton on 9 Dec 2009 16:51 "Daniel A. Galant" <daniel.galant(a)mindsharp.com> wrote in news:en4uXxQeKHA.5608(a)TK2MSFTNGP05.phx.gbl: > "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. No, it's not stored in SQL Server. It's like collaboration with other document types (Word, Excel, etc.), in that the document (in the case, an ACCDB) is stored on the Sharpoint server (not in SQL Server or as Sharepoint lists), and Access Services manages synchronizing design changes to the ACCDB. [] >> 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. Not for web publication, but for distribution, it's still possible. Albert makes this distinction explicitly in his discussions about web vs. client forms. You're basically calling Albert a liar. I don't know who the hell you are are, but I know Albert, and I believe him and not you. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Rick Brandt on 9 Dec 2009 18:56 David W. Fenton wrote: > No, it's not stored in SQL Server. It's like collaboration with > other document types (Word, Excel, etc.), in that the document (in > the case, an ACCDB) is stored on the Sharpoint server (not in SQL > Server or as Sharepoint lists), and Access Services manages > synchronizing design changes to the ACCDB. I believe all such "documents" are stored in a SQL Server BLOB field so they are technically in a SS table.
From: Albert D. Kallal on 10 Dec 2009 07:36 "Daniel A. Galant" <daniel.galant(a)mindsharp.com> wrote in message news:en4uXxQeKHA.5608(a)TK2MSFTNGP05.phx.gbl... > 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. > Correct. However, those forms and changes ARE saved on SharePoint! The forms are SERIALIZED out just like when we use source code control. (ie: saved out as separate objects). (look up the word serialized if you want more on this term). Thus, much of the check in/check out features of SharePoint are at work here. This stuff is so very new to a LOT OF people here. I am not worried when some here are not quite up to speed. It just means we have a good amount of education that needs to occur here. So, the flurry of new questions on SharePoint and access are quite "enjoyable" to say the least! So, as mentioned, published Access applications can LEGALLY have a mix of VBA forms, and WEB only forms. BOTH TYPES of forms are allowed in web applications. However, as mentioned ONLY the web forms can be used by "access web services". Changes to web only forms, or a changes to a VBA only forms are saved by sync. "client only VBA objects" are saved and synced. Because of the above ability to sync parts of the application, we can now "boot leg" this feature of SharePoint and Published access applications and use this feature to "distribute" our rich VBA applications. To be 100% specific clear here, we talking about a web based application but that application in our current example has no web forms. It is comprised of VBA only forms. I should point out that just like using source code control for ms-access applications EACH object is saved SEPARATE on the server. I think pointing out this issue will likely answer some questions here, but at the same time raise more questions! (I am debating if it good to even show this screen shot!!) Anyway, I will.... Here is a screen shot of the SharePoint site: http://nrfu5a.bay.livefilestore.com/y1pfBMYrXvv9dr8P0T5X6jITlOluooxm7H5KffNiSsf5V8I6JCymOyaJEr-W4iwuH9wvfy3rKhIMAC8ftDwz5CoTwjGCCvYsIn5/SharePointFiles.png Note that this screen shot is from the CTP beta preview, and it shows the VBA form as a web form, but that is incorrect. However note the yellow hand I put in that is pointing to a VBA ONLY form in this list. They are saved in the web site along with web forms that access creates after publishing. I have not yet setup a new SharePoint server, and when I do...I will spend time resolving this issue of how to "over write" existing individual forms, or a reverting to a "saved" pervious versions we have on the hard drive. There is also a series of steps one can take to un-publish an application, but it rather painful and again how to do this is another long story/post I shall no doubt have to make. I have become VERY busy with work and the holidays, so it going to be about 2 weeks before I can get back to playing with SharePoint (I expect then is when I should have a new SharePoint system up and running). -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 10 Dec 2009 11:58 "Salad" <salad(a)oilandvinegar.com> wrote in message news:ht-dnd1feLuyvrzWnZ2dnUVZ_rWdnZ2d(a)earthlink.com... > Albert D. Kallal wrote: > >> There is also a series of steps one can take to un-publish an >> application, >> but it rather painful and again how to do this is another long story/post >> I shall no doubt have to make. >> >> I have become VERY busy with work and the holidays, so it going to be >> about 2 >> weeks before I can get back to playing with SharePoint (I expect then is >> when I should have a new SharePoint system up and running). >> > I am curious as to how table changes would be made. I assume there'd be > no problem with adding a new table. But what if you had a table with a > field LastName that is 5 chars in length and you want to expand to 20, or > add a new field. Is it seemless? Well, I should point out for this discussion we were talking NOT about SharePoint data tables in this example. However, for linked SharePoint tables? Table changes in the client side to SharePoint occur in real time and are NOT held back by use of the sync feature. In other words, sync is NOT applying to table design changes for SharePoint lists (talking about upsized data tables from access to SharePoint lists in a WEB application). In other words, you add a new column, add a new index, set an existing index as unique etc, change the length of a field, add a new calculated column, you are doing this on the live data and in real time. There is no need sync (shall I say no ability! to sync) when modifying the table structures in the access client app that is connected to the tables (list) on the SharePoint server. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 10 Dec 2009 12:10
"Bob Alston" <bobalston9(a)yahoo.com> wrote in message news:0ZUTm.26638$gd1.11362(a)newsfe05.iad... > >>>> 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. >> >> No, it's not stored in SQL Server. It's like collaboration with >> other document types (Word, Excel, etc.), in that the document (in >> the case, an ACCDB) is stored on the Sharpoint server (not in SQL >> Server or as Sharepoint lists), and Access Services manages >> synchronizing design changes to the ACCDB. > Is it possible that he was referring to the fact that the sharepoint > dat/lists etc. are themselves stored in SQL server? No, I was not referring to the actual SharePoint data store. I was referring to that you can legally have split databases with the back end data as Sql server, (or any odbc server), or the back end can be ms-access back ends. This setup is possible now with a "published" web access application. But, those links will ONLY work for client side (non web) based objects (forms, reports query, VBA code etc.) that happens to exist in that published access application. So, we can publish our applications and NOT use SharePoint as where the data for the access application will reside (but, this only works for non web forms). Unfortunately, for access web services, you are not allowed external data sources (even the BDC (business data catalog - this was cut quite late in the program....). You can however use .net and "sink" the access forms into custom .net code that pulls data from other sources into lists (but, this would be a whole other ball game/post). At the end of the day, it is true that darn near everything in SharePoint is ultimately saved in a super sql database server "blob" of a database. To be clear, I was not making any reference to the issue that SharePoint uses sql server as an data store for almost everything.... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com |