Using Sharepoint 2010 for data storage but still running full Access client with vba and normal forms
in [Help]
|
From: David W. Fenton on 6 Dec 2009 16:37 Bob Alston <bobalston9(a)yahoo.com> wrote in news:QgISm.38494$cX4.11639(a)newsfe10.iad: > once an access database is published - data and other objects - to > Sharepoint 2010 - can you talk more about how any authorized user > can access the Access windows client and download it and run it on > the desktop and still be using or at least updating/syncing with > the data on Sharepoint. From what I have tried, it appears that > the Access front end becomes named <sharepointworkspace>.accdw I also wonder about controlling distribution. That is, the programmer makes changes to the source ACCDB app and I'd assume that once the changes are synched with the Sharepoint server version, everybody gets the updates. That means the programmer has to be careful to be sure not to synch before everything has been tested. A usual scenario using Tony's FE Updater would be: 1. developer copy of front end on developer's PC. 2. beta copy on server, updated when the developer wants to push out a new update to the beta testers. 3. the users who are beta testers have a shortcut that points to the updater script for the beta version, and will get the beta copy if the click that shortcut. 4. production version on server, updated when the developer has determined that beta version has passed testing successfully. 5. all users have a shortcut that runs the updater script to pull down this copy. I'm having a hard time, based on what little I know about the publishing/synching capabilities of Sharepoing, imagining how Sharepoint could work with this scenario. I've heard nothing about controlling this kind of thing with the built-in synchronization. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 6 Dec 2009 16:41 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:uAAQFBkdKHA.5136(a)TK2MSFTNGP02.phx.gbl: > 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, can you look at my other post, replying to Bob, asking about version control issues with synchronizing a published app? It sounds like an all-or-nothing situation, and that the developer will need to be very careful to not synchronize prematurely. This makes it hard to maintain beta versions, though I guess you could beta test by manually giving the users the beta front end (or use Tony's updater), but that means you've made it easier to accidentally publish the beta version (by synching too soon). Is it possible to roll back changes that have been synched without editing out the changes? -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Albert D. Kallal on 7 Dec 2009 06:13 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CD9A9BF68F92f99a49ed1d0c49c5bbb2(a)74.209.136.99... > "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in > news:uAAQFBkdKHA.5136(a)TK2MSFTNGP02.phx.gbl: > > Albert, can you look at my other post, replying to Bob, asking about > version control issues with synchronizing a published app? It sounds > like an all-or-nothing situation, and that the developer will need > to be very careful to not synchronize prematurely. Well, if you save a word document, or the act of saving a form, or hitting send on your email, is this any different? I mean, one has to assume one does not want to sync your forms/code etc. until you ready?. However, I not really sure I understand how this is related to un-doing changes? As a developer you ALREADY had made the changes regardless if you synced or not. In other words, the act of making changes is somewhat separate from hitting sync. if you made changes, and not synced, then I don't see how this is any different from developing in ms-access now? I mean, if you don't want to sync, then don't sync ??? However, if you made changes you don't want, then syncing not going to fix or change the fact that you made changes you don't want... > > Is it possible to roll back changes that have been synched without > editing out the changes? > Hum, I doubt this is much different then hitting save for a document, or saving a form in ms-access. We really never had the ability roll back out AFTER we saved a form or code. The only exception if we were using source code control, then yes you could roll your changes back to a previous version (in fact you can roll back to multiple different versions with source code control). It possible I not understanding the question here, but one simply to revert back a form or some code that you changed, then do what we always done: go to the backup copy and cut+paste the code, or if it whole form we messed up, delete the form, and import the form from the backup copy. I mean, sure, if you hit sync already, then import the form, and then whack sync to send out what the original form was. I assume you always make a backup copy before you start working. I don't see anything here that would suggest you stop making backups of your work. We don't have version controls now, and if you work all day long, and then mess up one form, you not going to the backup and going to copy over your work. In most cases you are key just recovering the one bit of code or form or report or query from the backup. it is possible that your process of reverting back to some previous code is diffent then how I work, so I suppose your mileage would vary on this issue.. I suppose at the end of the day there might be some new issues to deal with. Such as perhaps when you import a form from the backup copy the timestamp or some such is not updated. Perhaps one might have to "dirty" the form, but I am not aware of this issue as of yet. It certainly something I just don't have experience with at this point in time, but my current understanding of this does not see a particular problem that any differnt then what an average developer ALWAYS had to deal with.. There are some other big questions and big issues I see for syncing out changes, but that of revering back to a form or some code in a backup copy is not one those concerns or issues I see as a problem. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 7 Dec 2009 06:29 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message > > I'm having a hard time, based on what little I know about the > publishing/synching capabilities of Sharepoing, imagining how > Sharepoint could work with this scenario. I've heard nothing about > controlling this kind of thing with the built-in synchronization. > I think the decision here is will one work on a copy that is attached to the live data or not. If one is not going to work on the live copy that being synced, then you don't have a problem of syncing by accident. But then again one would not really be using the sync ability to keep this updated anyway. If you have a separate dev system, then you would have to re-link tables to production data. You then take the dev copy and overwrite the production copy. We will just have to get more experience with this issue as time unfolds. You can see my other post here when I mention versioning. As I mention, I don't think the issue of going back to old forms or code is an new issue. Ensuing that a 100% new dev copy gets sent out may need some extra steps to ensure this works. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 7 Dec 2009 06:33
"David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CD9A7CFE7F3Ff99a49ed1d0c49c5bbb2(a)74.209.136.99... > "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. > > -- Yes, you can have linked tables to standard ms-access back end, or even sql server. You not have web parts, but what you propose is legal. So, yes, the above even works with linked tables to a standard access backend. The back end on the server will not be pushed down by SharePoint and users would have to have legal file permissions to that back end path, but yes, the FE with linked tables to sql server or an access back end will work for this setup. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com |