Using Sharepoint 2010 for data storage but still running full Access client with vba and normal forms
in [Help]
|
From: David W. Fenton on 7 Dec 2009 22:15 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:#XzrJCzdKHA.1592(a)TK2MSFTNGP06.phx.gbl: > "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. The paragraph above seems to apply to data. I wasn't talking about data, only the front end. > 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. The paragraph above is uninformative to me -- I don't understand anything it says. If you've got a front end that you're distributing through Sharepoint, don't users get the updates when you synch front-end changes to the server? If so, how do you control that? If not, then I seem to have really misunderstood something somewhere along the line. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 7 Dec 2009 22:23 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:9r5Tm.75090$W77.73956(a)newsfe11.iad: > "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? Front-end development is an order of magnitude more complicated. That's why version control systems exist for software but not for MS Word documents. > 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 had to roll back a beta version today. It was easy -- the user who had the test version just reverted to the version before the one I'd given him on Friday. I didn't revert the development copy to the previous code. I can't see how the Sharepoint distribution system could handle that, at least not based on my understanding of how it works. And none of your comments address the beta vs. production issue. > 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... Are you being purposefully obtuse here? It's really easy to prematurely publish. I've done it numerous times and had to quickly roll out a replacement. With file-based distribution, I just revert to the previous file version. With Sharepoint distribution, I don't know how this would work. Could you keep a copy of the old and synch it? Would that destroy the changes synched from the later version? >> 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. But we have the ability to save versions of our front end as individual files and rollback to those. > 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). I think you're trying really hard to ignore what seems to me to be something that is flawed and is going to make the feature pretty much useless for ongoing development projects. [] > 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. You haven't even touched on the beta vs. production issue. Based on that, I'd guess that Tony's front-end updater is not going to be obsoleted by Sharepoint distribution. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Albert D. Kallal on 8 Dec 2009 03:26 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message > > I had to roll back a beta version today. It was easy -- the user who > had the test version just reverted to the version before the one I'd > given him on Friday. > > I didn't revert the development copy to the previous code. > Right, and to do that you kept a copy of that version ...right? > > I can't see how the Sharepoint distribution system could handle > that, at least not based on my understanding of how it works. > > And none of your comments address the beta vs. production issue. > I had thought I did??? I said if you working on your dev system, then before deployment you have to re-link to production data. You then overwrite the existing production copy on the server. However, it would be quite funny if you were not to make a copy of that before you do this? I also stated and brought up there might be some timestamp issues, but we have to learn this as we go along. So, I am assuming one would do what they ALWAYS done and work on a copy on their dev system. (both data and FE). I also assuming that before deployment we going to save a copy of that FE? You could not possibility be standing here as an serious developer and telling me that this needs to be told to everyone? Again I don't really see the version issue as being any different at all here? How is keeping a copy of the version from your dev system before you deploy going to be any different now? Surely you jest that it needs pointing out that developers don't know to save a copy of the current version before they deploy? I stated in my other post that their might be some different issues in terms of a timestamp issue that we figure out over time with more experience. Other then this timestamp issue I pointed out, why would someone not keep a copy of the particular production version before they deploy? > Are you being purposefully obtuse here? It's really easy to > prematurely publish. No, I am not. But I think if we have to stand here and tell people that they need to make a copy of their software before they deploy then we really sinking to new lows in this group are we not? > Could you keep a copy of the old and synch > it? Would that destroy the changes synched from the later version? > I stated that I don't see why we can't in that other post. I don't see why we can't over write the copy on the server. > > But we have the ability to save versions of our front end as > individual files and rollback to those. > Right, and why would you not continue that practice? I just don't see this problem? I not convinced that just using SharePoint to distribute a front end is the best use of SharePoint. However, if it is available, it would facilitate new users of the application not needing some type of install or setup like Tony's updater system. Keep in mind while you can use linked tables to a BE, or linked tables to SQL server, you can NOT have local tables in the front end when you do this. I just assumed that every developer on the planet would keep a copy and that part never needed pointing out or even crossed mind. So, yes, I did point out the ONE issue of timestamps, and the possibility some issues arising out of timestamps. However if it helps, yes, before you decide to overwrite that copy sitting on SharePoint, you want to make a copy to save that version in case you need to revert back to it... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 8 Dec 2009 16:09 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:W4oTm.17342$_b5.5426(a)newsfe22.iad: > "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message > >> I had to roll back a beta version today. It was easy -- the user >> who had the test version just reverted to the version before the >> one I'd given him on Friday. >> >> I didn't revert the development copy to the previous code. > > Right, and to do that you kept a copy of that version ...right? Yes, but a WHOLE FILE. I didn't copy anything into the new file, but simply distributed the previous version in place of the current version until current development version was ready for release (to the beta tester, as a matter of fact). Can you synch your development copy and then revert to a previous version of the file and synch and have it undo the 1st of those two synchs? >> I can't see how the Sharepoint distribution system could handle >> that, at least not based on my understanding of how it works. >> >> And none of your comments address the beta vs. production issue. > > I had thought I did??? I said if you working on your dev system, > then before deployment you have to re-link to production data. The issue has NOTHING to do with production data, or with any kind of data. My question is all about front-end distribution -- I am not contemplating Sharepoint for data at all at this point. > You then > overwrite the existing production copy on the server. However, > it would be quite funny if you were not to make a copy of that > before you do this? I also stated and brought up there might > be some timestamp issues, but we have to learn this as we > go along. First off, my clients don't have different servers. Most of them don't have *any* servers, so talk of a "production server" is simply laughable. I outlined a common system, using Tony's front-end updater, where beta testers have two shortcuts, one to launch the latest beta, one to launch the production database. You haven't addressed how to map that system onto Sharepoint distribution of a front end. > So, I am assuming one would do what they ALWAYS done and work > on a copy on their dev system. (both data and FE). I also > assuming that before deployment we going to save a copy of > that FE? You could not possibility be standing here as an > serious developer and telling me that this needs to be told > to everyone? You're assuming a lot of things and ignoring my actual description of the architecture in question. > Again I don't really see the version issue > as being any different at all here? How is keeping a copy of > the version from your dev system before you deploy going to > be any different now? I'm not talking about keeping the development versions. I'm talking about how users get the changes. How does one manage with Sharepoint updating of a front end to maintain the difference between your beta front end and your production front end? Is it as simply as keeping the development copy in one folder on the developer's machine, synching that to the server, and then moving it to a different folder on the development machine when it's ready for production distribution and then synching that with Sharepoint? Does Sharepoint see it as a different source database because it's in a different location? If so, that would work, I guess. But I'm guessing -- this is what I'm asking you about, and you're mixing in a bunch of imaginary stuff out of your own head about production servers, instead of starting from the scenario I described. > Surely you jest that it needs pointing out that developers don't > know to save a copy of the current version before they deploy? > > I stated in my other post that their might be some different > issues in terms of a timestamp issue that we figure out over time > with more experience. > > Other then this timestamp issue I pointed out, why would someone > not keep a copy of the particular production version before they > deploy? Perhaps you're too close to understand what I don't understand. Of course I save copies of each development stage. Indeed, I rename my front end as I develop with the expected release date. The app that got reverted last week now has a development copy named lionheartDB20091210.mdb, because it's intended to be released on Thursday (it may or may not be). When it's ready for testing, I'll strip the dates from the filename and send it to my tester who will place it in his testing folder and test it (they use live data, as the point of the testing is to figure out if it is stable enough for daily use). When it's determined that its ready for production use, it then gets copied to the folder from which the production front end is distributed (it's actually a manual process, but that's immaterial here, as the questions are not about the mechanism, but about managing the process). I am still working on lionheartDB20091210.mdb until the beta goes into production, at which time I copy it to the archive and rename the development copy to the next expected release date. Now, in a Sharepoint front-end distribution scenario, what I imagine is that once each user has a copy of the front end, they just choose to synch with the Sharepoint server whenever they are informed that there are updates to the front end. In that scenario (assuming it's correct), how would I keep the regular users from getting the beta version, other than telling them not to synch? How does Access know which Sharepoint-distributed front end to synch with (I don't know what the appropriate terminology is for the Sharepoint feature of distributing and synching a front end)? How could I copy the beta version to production and have Access know that it now needs to synch with the Sharepoint production version instead of the Sharepoint beta version? >> Are you being purposefully obtuse here? It's really easy to >> prematurely publish. > > No, I am not. But I think if we have to stand here and tell people > that they need to make a copy of their software before they deploy > then we really sinking to new lows in this group are we not? It's not a matter of keeping a backup, but a matter of changes going out prematurely to the users. It's not clear to me from your answers if in that scenario I can revert by simply copying the backup file over top of the new file and then resynching (of course, I wouldn't actually copy over top of it, just rename, copy to the old file name, resynch, and then go back to the prematurely-published version). >> Could you keep a copy of the old and synch >> it? Would that destroy the changes synched from the later >> version? > > I stated that I don't see why we can't in that other post. I don't > see why we can't over write the copy on the server. But does it actually work? I'm not in a position to test, nor are many other people. >> But we have the ability to save versions of our front end as >> individual files and rollback to those. > > Right, and why would you not continue that practice? I just don't > see this problem? > > I not convinced that just using SharePoint to distribute a front > end is the best use of SharePoint. However, if it is available, it > would facilitate new users of the application not needing some > type of install or setup like Tony's updater system. Your answers have almost convinced me that Sharepoint won't be able to replace Tony's updater (or any similar system). You say "I don't see why we can't" in regard to the question of copying an older version over top of a newer and resynching, but that's not good enough. "Can't see why not" is not sufficient -- I would need to know whether it works or not. I can't see how it would, to be honest, but my perspective on that is with Jet replication, where you can't undo a synch, except by actually editing the data to reflect the previous state. > Keep in mind while you can use linked tables to a BE, or linked > tables to SQL server, you can NOT have local tables in the front > end when you do this. > > I just assumed that every developer on the planet would keep a > copy and that part never needed pointing out or even crossed mind. You're completely missing the point, Albert. > So, yes, I did point out the ONE issue of timestamps, and the > possibility some issues arising out of timestamps. However if it > helps, yes, before you decide to overwrite that copy sitting on > SharePoint, you want to make a copy to save that version in case > you need to revert back to it... But *can* you revert back to it? I wasn't suggesting that one didn't keep copies. I was only asking if the premature synch is reversible. You say you "don't see why you can't," which is not an answer at all. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Daniel A. Galant on 8 Dec 2009 18:30
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. -- 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:Xns9CDBA44DF911Ff99a49ed1d0c49c5bbb2(a)74.209.136.90... > "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in > news:W4oTm.17342$_b5.5426(a)newsfe22.iad: > >> "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message >> >>> I had to roll back a beta version today. It was easy -- the user >>> who had the test version just reverted to the version before the >>> one I'd given him on Friday. >>> >>> I didn't revert the development copy to the previous code. >> >> Right, and to do that you kept a copy of that version ...right? > > Yes, but a WHOLE FILE. I didn't copy anything into the new file, but > simply distributed the previous version in place of the current > version until current development version was ready for release (to > the beta tester, as a matter of fact). > > Can you synch your development copy and then revert to a previous > version of the file and synch and have it undo the 1st of those two > synchs? > >>> I can't see how the Sharepoint distribution system could handle >>> that, at least not based on my understanding of how it works. >>> >>> And none of your comments address the beta vs. production issue. >> >> I had thought I did??? I said if you working on your dev system, >> then before deployment you have to re-link to production data. > > The issue has NOTHING to do with production data, or with any kind > of data. My question is all about front-end distribution -- I am not > contemplating Sharepoint for data at all at this point. > >> You then >> overwrite the existing production copy on the server. However, >> it would be quite funny if you were not to make a copy of that >> before you do this? I also stated and brought up there might >> be some timestamp issues, but we have to learn this as we >> go along. > > First off, my clients don't have different servers. Most of them > don't have *any* servers, so talk of a "production server" is simply > laughable. > > I outlined a common system, using Tony's front-end updater, where > beta testers have two shortcuts, one to launch the latest beta, one > to launch the production database. You haven't addressed how to map > that system onto Sharepoint distribution of a front end. > >> So, I am assuming one would do what they ALWAYS done and work >> on a copy on their dev system. (both data and FE). I also >> assuming that before deployment we going to save a copy of >> that FE? You could not possibility be standing here as an >> serious developer and telling me that this needs to be told >> to everyone? > > You're assuming a lot of things and ignoring my actual description > of the architecture in question. > >> Again I don't really see the version issue >> as being any different at all here? How is keeping a copy of >> the version from your dev system before you deploy going to >> be any different now? > > I'm not talking about keeping the development versions. I'm talking > about how users get the changes. How does one manage with Sharepoint > updating of a front end to maintain the difference between your beta > front end and your production front end? Is it as simply as keeping > the development copy in one folder on the developer's machine, > synching that to the server, and then moving it to a different > folder on the development machine when it's ready for production > distribution and then synching that with Sharepoint? Does Sharepoint > see it as a different source database because it's in a different > location? If so, that would work, I guess. > > But I'm guessing -- this is what I'm asking you about, and you're > mixing in a bunch of imaginary stuff out of your own head about > production servers, instead of starting from the scenario I > described. > >> Surely you jest that it needs pointing out that developers don't >> know to save a copy of the current version before they deploy? >> >> I stated in my other post that their might be some different >> issues in terms of a timestamp issue that we figure out over time >> with more experience. >> >> Other then this timestamp issue I pointed out, why would someone >> not keep a copy of the particular production version before they >> deploy? > > Perhaps you're too close to understand what I don't understand. > > Of course I save copies of each development stage. Indeed, I rename > my front end as I develop with the expected release date. The app > that got reverted last week now has a development copy named > lionheartDB20091210.mdb, because it's intended to be released on > Thursday (it may or may not be). When it's ready for testing, I'll > strip the dates from the filename and send it to my tester who will > place it in his testing folder and test it (they use live data, as > the point of the testing is to figure out if it is stable enough for > daily use). When it's determined that its ready for production use, > it then gets copied to the folder from which the production front > end is distributed (it's actually a manual process, but that's > immaterial here, as the questions are not about the mechanism, but > about managing the process). > > I am still working on lionheartDB20091210.mdb until the beta goes > into production, at which time I copy it to the archive and rename > the development copy to the next expected release date. > > Now, in a Sharepoint front-end distribution scenario, what I imagine > is that once each user has a copy of the front end, they just choose > to synch with the Sharepoint server whenever they are informed that > there are updates to the front end. > > In that scenario (assuming it's correct), how would I keep the > regular users from getting the beta version, other than telling them > not to synch? > > How does Access know which Sharepoint-distributed front end to synch > with (I don't know what the appropriate terminology is for the > Sharepoint feature of distributing and synching a front end)? How > could I copy the beta version to production and have Access know > that it now needs to synch with the Sharepoint production version > instead of the Sharepoint beta version? > >>> Are you being purposefully obtuse here? It's really easy to >>> prematurely publish. >> >> No, I am not. But I think if we have to stand here and tell people >> that they need to make a copy of their software before they deploy >> then we really sinking to new lows in this group are we not? > > It's not a matter of keeping a backup, but a matter of changes going > out prematurely to the users. It's not clear to me from your answers > if in that scenario I can revert by simply copying the backup file > over top of the new file and then resynching (of course, I wouldn't > actually copy over top of it, just rename, copy to the old file > name, resynch, and then go back to the prematurely-published > version). > >>> Could you keep a copy of the old and synch >>> it? Would that destroy the changes synched from the later >>> version? >> >> I stated that I don't see why we can't in that other post. I don't >> see why we can't over write the copy on the server. > > But does it actually work? I'm not in a position to test, nor are > many other people. > >>> But we have the ability to save versions of our front end as >>> individual files and rollback to those. >> >> Right, and why would you not continue that practice? I just don't >> see this problem? >> >> I not convinced that just using SharePoint to distribute a front >> end is the best use of SharePoint. However, if it is available, it >> would facilitate new users of the application not needing some >> type of install or setup like Tony's updater system. > > Your answers have almost convinced me that Sharepoint won't be able > to replace Tony's updater (or any similar system). You say "I don't > see why we can't" in regard to the question of copying an older > version over top of a newer and resynching, but that's not good > enough. "Can't see why not" is not sufficient -- I would need to > know whether it works or not. > > I can't see how it would, to be honest, but my perspective on that > is with Jet replication, where you can't undo a synch, except by > actually editing the data to reflect the previous state. > >> Keep in mind while you can use linked tables to a BE, or linked >> tables to SQL server, you can NOT have local tables in the front >> end when you do this. >> >> I just assumed that every developer on the planet would keep a >> copy and that part never needed pointing out or even crossed mind. > > You're completely missing the point, Albert. > >> So, yes, I did point out the ONE issue of timestamps, and the >> possibility some issues arising out of timestamps. However if it >> helps, yes, before you decide to overwrite that copy sitting on >> SharePoint, you want to make a copy to save that version in case >> you need to revert back to it... > > But *can* you revert back to it? I wasn't suggesting that one didn't > keep copies. I was only asking if the premature synch is reversible. > You say you "don't see why you can't," which is not an answer at > all. > > -- > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ |