Using Sharepoint 2010 for data storage but still running full Access client with vba and normal forms
in [Help]
|
From: David W. Fenton on 10 Dec 2009 15:07 Bob Alston <bobalston9(a)yahoo.com> wrote in 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? If so, it's still completely irrelevant, since we weren't talking about data storage. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 10 Dec 2009 15:09 Rick Brandt <rickbrandt2(a)hotmail.com> wrote in news:hfpdfo$a1i$2(a)news.eternal-september.org: > 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. Even so, it's not relevant to the current topic of discussion, which was completely missed by the correspondent in question. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Daniel A. Galant on 10 Dec 2009 15:44 Excuse me David, but maybe there has been more of this discussion somewhere else, I have only been following the thread on the microsoft.public,sharepoint.general forum. That particular thread topic happens to be "Using SharePoint 2010 for data storage...." so forgive me if I thought this had something to do with actually storing data. -- Daniel A. Galant Imagine what we could be... if we could just imagine. "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CDD99E5F6E55f99a49ed1d0c49c5bbb2(a)74.209.136.91... > Bob Alston <bobalston9(a)yahoo.com> wrote in > 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? > > If so, it's still completely irrelevant, since we weren't talking > about data storage. > > -- > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Albert D. Kallal on 10 Dec 2009 16:29 "Salad" <salad(a)oilandvinegar.com> wrote in message > > Count me confused. I thought the data tables were stored in/on the > Sharepoint server (after publishing) and the links I might have would be > on the local machine pointing to those published tables on the Sharepoint > server. > > One can change the table structure without "exclusive use"? I guess that > question got me started on my first post. > Yes, you can change tables (In fact, I not sure you even need exclusive use either). Hence, after you published, design changes to web forms, web reports, web quires etc are still changed on the client side (and, then you hit sync to send up those changed objects). However, for those linked tables, you can also modify the designs in the client side. If you add new columns, or modify indexes etc, those changes occur while your in design mode and you do NOT have to hit the sync button to make tables changes occur. So, after you published, yes, the tables/data are located on SharePoint, but you still use the tools in ms-access to modify the table structures. I have not tested this, but I do believe some changes are allowed while users are even working on the data. This would not be the first such system I worked on over the years that allows changes to data structures while users are working on the data. I suspect that deleting a column requires exclusive use, but adding new columns should work even while other users are working. I have to test this. So, I am not 100% sure of the exclusive issue(s), but I am 100% sure about changing tables and not needing to "sync" when you do modify the structure of the tables (of which are now linked to SharePoint). -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 11 Dec 2009 04:24
"Salad" <salad(a)oilandvinegar.com> wrote in message >> > Ok. I opened up my local mdb and the table. It was linked to Sharepoint. > I then added a column to the table in SharePoint. Right, be we were talking about making the modifying in the client (since modifying forms, etc. needs one to "sync" the application after changes been made). Keep in mind, that linked tables to SharePoint as oppose to published applications are still somewhat different. Published applications ALLOW the table designs to be modified from the access client. Where as a linked tables to SharePoint does NOT allow one to make changes to the table. > Then I did a Record/Refesh in the mdb and no new column. When I closed the > table and reopened it the new field existed. So exclusive use was not > required. Well, the above is likely same behavior would be seen if you had a linked table to sql server. You have to re-link to see the new column. The above observation still does not preclude the issue of exclusive access to the table being required. So, doing the reverse was really the question here (making the changes to the tables in ms-access that exist on SharePoint). > I opened up the web page that had a data entry form based on the > sharepoint table and then I added another column and it didn't affect the > web page either. As mentioned, I don't believe you need exclusive table rights to modify or add columns, but I have to test/try this. No question you can modify or add columns to the SharePoint list using the SharePoint options, but the question was can you do the same from the access 2010 client? Do keep in mind it only access 2010 that has this "new" ability to allow table design changes from the client AFTER the application been published. Regardless of the above issues, using of the "sync" option is NOT required or needed to send up table design changes...they occur in real time and thus can't be done in "off line" mode. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com |