 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Replication / June 2005Replication/Sychronization of Disconnected laptops
Access 2000. I have read a little about replication and synch. Iv'e created a master on my stationary computor in the office and a replica on a laptop which I use in the field. The laptop will always be disconnected, no networking etc. My hope is to somehow synchronize the laptop with the office computor via floppydisk. This is the only way can do it. The goal is no duplication of data...Any ideas...Randy > Access 2000. I have read a little about replication and synch. > Iv'e created a master on my stationary computor in the office and [quoted text clipped - 3 lines] > This is the only way can do it. The goal is no duplication of > data...Any ideas...Randy Can't do it. Replication is not designed for completely disconnected scenarios. If you try it, it will seem to work for a while, but after a long enough period of time, you'll accumulate so many dead replicas that you'll end up corrupting the replica set.  SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc Are there any other options/scenarios? >> Access 2000. I have read a little about replication and synch. >> Iv'e created a master on my stationary computor in the office and [quoted text clipped - 11 lines] > enough period of time, you'll accumulate so many dead replicas that > you'll end up corrupting the replica set. >>> Access 2000. I have read a little about replication and synch. >>> Iv'e created a master on my stationary computor in the office [quoted text clipped - 14 lines] > > Are there any other options/scenarios? Well, it depends on a number of factors: 1. will data need to be simultaneously added in both databases? 2. will data need to be simultaneously edited in both databases? 3. would the databases be used to create and manage two overlapping but mostly separated sets of data? If the amount of 1 & 2 is relatively limited (e.g., most records are added in one database or the other, and/or most of the editing takes place in one or the other), it's not impossible to program the synchronization of data with SQL. It's not trivial. It requires quite a bit of planning, especially if the database schema has a number of hierarchically-related tables. But it is doable. It's much easier if one of the databases is the master and one the slave, or if the data being added/edited by in each database does not really overlap. But it can be done. It's just very, very complicated, and resolving conflicts comes to the foreground much more quickly than you ever have to deal with it with Jet replication. SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc Wow, sounds like I'm out of solutions. Right now the master db in the office collects all the data from the field laptops via floppy disk. The laptop has a copy of the main db. The data is exported to via transfer spreadsheet to a floppy. I then import the data from an excel file on the floppy to the main db. The problem is there are occasional duplicates... >>>> Access 2000. I have read a little about replication and synch. >>>> Iv'e created a master on my stationary computor in the office [quoted text clipped - 43 lines] > conflicts comes to the foreground much more quickly than you ever > have to deal with it with Jet replication. > Wow, sounds like I'm out of solutions. Right now the master db in > the office collects all the data from the field laptops via floppy > disk. The laptop has a copy of the main db. The data is exported > to via transfer spreadsheet to a floppy. I then import the data > from an excel file on the floppy to the main db. The problem is > there are occasional duplicates... Well, replication wouldn't necessarily have fixed that, depending on how you define "duplicates." I think you need to rethink the basic architecture of your entire project. Add in a network connection for every remote PC (Internet is sufficient) and you've multiplied your options many times. SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc >Access 2000. I have read a little about replication and synch. Iv'e >created a master on my stationary computor in the office and a replica on a >laptop which I use in the field. The laptop will always be disconnected, no >networking etc. My hope is to somehow synchronize the laptop with the >office computor via floppydisk. This is the only way can do it. The goal >is no duplication of data...Any ideas...Randy You will get advice from the regulars here that completely disconnected synchronization will not work. In general, I might agree with them. However, there is a workaround that works for me, but the cost of implementation might be too high for some people because it requires a number of steps, performed precisely in the right order and is more time consuming than some can stomach. If so, the regulars are right. If not, the following might work for you. You want to avoid over burdening your replica set with information that will, eventually (theoretically, at least), cause corruption. Usually, this is in the form of the replica information that Access maintains. As has been said, when a replica is removed from the replica set (or deemed removed because it has been replaced with another replica at the same location) the information Access stores about the removed replica is permanently (theoretically, at least) added to the information it stores. At some point (nobody really knows what this point is - see below), the entire replica set will corrupt and BAD THINGS WILL HAPPEN. Usually, this is translated as LOSS OF DATA. Loss of data is definitely a BAD THING. The solution is so simple (and has worked for me for over 4 years, with synchronization taking place weekly) that it boggles the mind (mine, anyway) why the regulars here get so darned upset whenever this (not overburdening the replica set) is suggested. Trust me, the flames are about to go sky high. So, the question is how to go about not overburdening the replica set with dead replica information? Simple. Completely rebuild the replica set after a synchronization. How to do that? Again, simple, although to do it right might take more time than you are willing to commit to each time: make one of the replicas the design master and re-replicate. In your case, AFTER APPROPRIATELY BACKING UP EVERYTHING, TWICE, try the following and see whether the replica information tables aren't "clean", or at least "stabalize" and don't grow. 1) Start with a design master. 2) Make replicas for use: a) Make a replica somewhere on your machine for your own use (one should never directly use the design master for data input). b) Make another replica somewhere on your machine whose sole purpose is to be copied to floppy for transport to your laptop. 3) Copy replica created in Step 2b to floppy. 4) Copy floppy replica to laptop at a specific location (when you do this again, the next time through these steps, make sure you use the same location). 5) Input additional information or change information into your replica on your laptop and on your machine. That is, happily use both replicas, one on your laptop the other on your machine. 6) Copy replica from laptop back to floppy. 7) Copy replica from floppy back to same location that you created in step 2b. 8) BACKUP EVERYTHING. All copies (the design master and the two replicas). 9) Run a routine that attempts to give you confidence about number of records in each table in the design master and the replicas. The programming of this step is quite simple and is worth its weight in gold as far as peace of mind goes. Just do it. 10) Synchronize both replicas to design master (twice), and resolve any conflicts. Synchronize the design master to both replicas after resolving conflicts (twice). 11) Run your routine created in step 9 just to gain confidence that the number of records in each table of all copies of the database havn't mysteriously been modified in unsuspected ways. 12) BACKUP EVERYTHING to a different location than you selected in step 8. 13) Delete your design master. 14) Copy one of your replicas to the location where the design master was. After your synchronization in step 10, it doesn't matter which replica you use, they are both functionally identical. 15) Go into the new copy of the replica (which is in the location where your design master was) and recover the design master from that replica. 16) Delete your other replicas (do not bother the backup copies created in steps 8 and 12 - keep them for a year or two - disk space is cheap - yes, I'm suggesting you save 6 copies of your data each time you do this). You are now back at step 1. Go into the design master and tell it you want to see hidden objects and system objects. Examine the tables with replica information. If, at any point in time it looks to you like there are too many records in any of the MSys... tables and you are worried about your information corrupting, you can even go one step further: remove replication from your design master after Step 15 and then re-replicate. I've never had to do that (re-replicate) in over 4 years. My MSys... tables are stable (the only reason they have anything in them above a few records is that I had some machines go "poof" on me in these last four years and I've never had to un-replicate the replica set - so I have a few dead replicas in my tables). My scenario is different (and more complicated) than yours because I am synchronizing 4 locations, not just 2. It takes me about 45 minutes each week to run all these steps. I actually run a few more steps than the ones I have laid out above because I also have a replica farm set up on the machine with the design master JUST IN CASE. Google "replica farm Kaplan" to see more information. In a perfect world (I've tried this before), the regulars in this newsgroup would engage in an even-handed discussion about the pros and cons of this method and would assist in determining what limits should be placed on the number of records in the MSys... files before re-replicating. They won't. Instead, they will just jump up and down about how BAD this method is, and that if you use it you will be PUTTING YOUR DATA AT RISK. And since PUTTING YOUR DATA AT RISK is a CARDINAL SIN, if you do so, you SHOULD BE FIRED, or SHUNNED, or COMMITTED TO AN INSANE ASYLUM. OR ALL THREE. I work for myself so can't be fired. I don't care about being shunned by closed minded "experts." We could argue about the third one. (g) ONE FINAL CAVEAT: If it doesn't work, don't blame me. BACKUP YOUR DATA. Good luck, mike Wow! Thanks for your input. At least there are other options...Thanks again Mike >>Access 2000. I have read a little about replication and synch. Iv'e >>created a master on my stationary computor in the office and a replica on [quoted text clipped - 157 lines] > > mike > Wow! Thanks for your input. At least there are other options You've been given extremely bad advice. Don't take it. I just don't see any reasons why you can't get a dialup Internet account for the remote PC. It doesn't have to connect often, it just has to be able to connect. Keep this in mind: If you follow the bad advice you've been given, there won't be anyone here in this newsgroup to advise you on how to fix any problems that arise. On the other hand, if you use replication within its design parameters, you'll have plenty of help here working through the complexities involved in the care and feeding of replicated Jet databases. SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc >>Access 2000. I have read a little about replication and synch. >>Iv'e created a master on my stationary computor in the office and [quoted text clipped - 7 lines] > disconnected synchronization will not work. In general, I might > agree with them. I'm one of the regulars who will advise against what you're suggesting. I have been using replicaion since 1997. I learned all the problems by making the mistakes early on. I lost replicas (though luckily, never an entire replica set). I spent hours manually synchronizing replicas. I spent hours cleaning up replica sets with large numbers of dead replicas. I learned how much easier it is to just use replication the way it was designed to be used. Back then, in the late 90s, WAN connectivity was very expensive (one client paid $400/month for a 56K fractional T1, and thought it was a great deal), and Windows Terminal Server was a very expensive proposition. Well, broadband is a reality nowadays and WTS comes included in all Windows servers, as well as being available on WinXP workstations. So, to me, it is no longer the case that it is too expensive or too difficult to run replication in its intended environment, or even to avoid replication altogether by using remote desktop/terminal server. > However, there is a workaround that works for me, but the cost of > implementation might be too high for some people because it [quoted text clipped - 14 lines] > some point (nobody really knows what this point is - see below), > the entire replica set will corrupt and BAD THINGS WILL HAPPEN. There are a number of reasons why there's no clear way to identify when things go awry, because each replica set is different, each synch history is different, each schema is different. Certain situations will likely corrupt sooner than others. But the main point of no return is when data errors prevent a successful synch. If the data error is in a dead replica, it is very hard (though not impossible) to get rid of that data error. Now, in Jet 4, data errors are just another form of conflict, so I don't know if they are more easily resolved. But, either way, you're weakening the reliability of your data by choosing to use replication outside its design parameters. > Usually, this is translated as LOSS OF DATA. Loss of data is > definitely a BAD THING. The first thing that happens is that as soon as you're in this state, you don't really know if all the replicas are synchronizing with each other successfully. That means you don't know if the data is identical in all the replicas, and that means you can no longer depend on the data. Now, that's not corruption of the data in the conventional sense -- what data is there remains accessible, but it's no longer *trustworthy* data. And since you can't know for sure when this state is reached, that's why the recommendation against using a setup that creates dead replicas is so strong. > The solution is so simple (and has worked for me for over 4 years, > with synchronization taking place weekly) that it boggles the mind > (mine, anyway) why the regulars here get so darned upset whenever > this (not overburdening the replica set) is suggested. Trust me, > the flames are about to go sky high. Your solution doesn't sound simple to me. It has a number of steps that have to be followed very carefully in order to avoid problems. All this work, just to avoid paying for a dialup Internet account! > So, the question is how to go about not overburdening the replica > set with dead replica information? Simple. Completely rebuild [quoted text clipped - 39 lines] > The programming of this step is quite simple and is worth its > weight in gold as far as peace of mind goes. Just do it. Are you also going to compare the data in every single field, or are you just going to convince yourself that tables with the same numbers of records actually contain identical data? > 10) Synchronize both replicas to design master (twice), and > resolve any conflicts. Synchronize the design master to both [quoted text clipped - 24 lines] > > You are now back at step 1. Not with the code you've described in Step 9. Only code that verifies that all tables have exactly the same records and that every field in every record is identical would actually assure you that something hasn't gone wrong. And, frankly, if you have code that does that, then why not just forget about starting over each round of synchs and simply mis-use replication without all the extra work? > Go into the design master and tell it you want to see hidden > objects and system objects. [quoted text clipped - 12 lines] > me in these last four years and I've never had to un-replicate the > replica set - so I have a few dead replicas in my tables). But you don't really know how much data you've lost, because you aren't really verifying that the data in your tables is identical. [] > In a perfect world (I've tried this before), the regulars in this > newsgroup would engage in an even-handed discussion about the pros [quoted text clipped - 3 lines] > > They won't. From my point of view, you're giving bad advice. You're telling someone to use replication in a manner that it wasn't designed for, and your advice of how to work around the problems is not even complete. My advice is to get the remote machines connected to the Internet, at which point all sorts of benefits for synchronizing data become available. I have a hard time imagining that this would be an insurmountable hardship, since even dialup is sufficient for indirect replication. You, on the other hand, are recommending a method that you admit takes you nearly an hour a week to keep running smoothly (that's nearly 50 hours a year, which is not an insignificant amount of money to me), as opposed to recommending spending a small amount of money to get the remote machines connected to each other. SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc I appreciate the tone of your response. I don't have time to respond in depth at the moment, but I will at first opportunity. Much of what you say makes perfect sense. In brief, I do not recommend the approach unless one is willing to convince themselves that the approach is workable and is willing to accept the consequences of being wrong. You mention that my 45 minutes per week is time that I might be able to invest in other activities if replication were performed via an alternate mechanism. Can you estimate the minutes via an alternate mechanism, or are you assuming that it is essentially zero and that 100% of my 45 minutes is "wasted"? mike > I appreciate the tone of your response. I don't have time to > respond in depth at the moment, but I will at first opportunity. [quoted text clipped - 10 lines] > alternate mechanism, or are you assuming that it is essentially > zero and that 100% of my 45 minutes is "wasted"? Well, I was comparing the time you spend in a year (and the cost that represents) to the cost of getting an Internet connection for the remote PC so that proper indirect replication could be set up. My point was that you're spending money on a manual process in the form of your time, and if it were spent on networking, replication could be used as it's intended without worrying about the problems that can occur when you try to use it in an environment it wasn't designed for. Now, I don't mean to claim that setting up indirect replication is easy and costs nothing in terms of time. But since that plus the Internet access costs would get you safety and save you the time of writing the code to verify that two replicas are identical, it seems preferable to me. SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc >> I appreciate the tone of your response. I don't have time to >> respond in depth at the moment, but I will at first opportunity. [quoted text clipped - 25 lines] >writing the code to verify that two replicas are identical, it seems >preferable to me. A couple of points (maybe three): 1) Some people doing it this way are doing so partially because they do not have MOD, so the cost of acquiring that needs to be figured in. 2) When I do my reconciliation I am, in the span of that 45 minutes, also "looking over" the data added to the database. This is an essential function that I would need to perform even if the replication were effortless. 3) This mechanism is all "direct" and therefore not only eliminates the setup of either indirect or internet replication it also eliminates any problems that might develop in using those technologies over time. You have indicated in the past that internet replication is persnickity at best. Indirect is less subject to falling over then internet, but still is a bit more prone than direct. None of the above is a magic bullet that eliminates the appropriateness of doing things the "right" way. But each is a factor that can impact the overall decision, one way or the other. mike >>> I appreciate the tone of your response. I don't have time to >>> respond in depth at the moment, but I will at first opportunity. [quoted text clipped - 44 lines] > subject to falling over then internet, but still is a bit more > prone than direct. Internet replication is something I've never used myself, because of the IIS-on-both-ends requirement, which I consider completely unacceptable (3 reasons: 1. IIS is just not safe to use anywhere, at least not before IIS 6 on Win2K3 Server; 2. functionality that is implemented via FTP, an open standard, should not require proprietary technology to use; 3. workstations should not be running FTP or Web servers, which is what Internet replication requires). Indirect replication is not itself "persnickity," but there are enough parts of the networking equation to keep in line that there are these two problems: 1. Access developers generally don't have the knowledge to understand what the networking issues are, either to implement or to administer over the long term, AND 2. when an Access developer is working with a sysadmin, there's often a communication problem, and a resistance to the requirements of indirect replication. This reluctance often means that the network infrastructure gets incompletely configured (or frequently reconfigured), causing indirect replication to break. So, yes, a direct replication solution is preferable to indirect when a LAN connection between remote and local replicas is possible. When it's not, indirect is vastly preferable to your kludge approach. In my opinion. > None of the above is a magic bullet that eliminates the > appropriateness of doing things the "right" way. But each is a > factor that can impact the overall decision, one way or the other. The MOD cost is a one-time expense. You could even pay an Access developer to put together an installer for you, since they have the license already and can produce apps with the distributable components. But that would probably cost somewhere around half the cost of MOD, and you wouldn't get any of the other benefits of having MOD. Yes, it's part of the equation, but in the long run, you're still comparing front-end costs vs. long-term recurring costs (even if you slice your weekly time in half by allocating half of it to data verification that you'd be doing anyway). SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc >>>Access 2000. I have read a little about replication and synch. >>>Iv'e created a master on my stationary computor in the office and [quoted text clipped - 32 lines] >Well, broadband is a reality nowadays and WTS comes included in all >Windows servers, as well as being available on WinXP workstations. I'm not sure a WinXP workstation can function as smoothly as a true Windows server when it comes to accepting connections from another computer. Am I wrong on that? For example, a windows server can accept a connection from just about any machine, I believe, while an XP Pro machine can only accept a connection from an XP Pro machine. Again, am I wrong on that? >So, to me, it is no longer the case that it is too expensive or too >difficult to run replication in its intended environment, or even to [quoted text clipped - 24 lines] >synch history is different, each schema is different. Certain >situations will likely corrupt sooner than others. True. But since I am essentially rebuilding my replica set each week, they aren't given the chance to corrupt. >But the main point of no return is when data errors prevent a >successful synch. If the data error is in a dead replica, it is very >hard (though not impossible) to get rid of that data error. True. Luckily, I have never been precluded from a successful synch. Maybe it is because I have the farm there waiting to pitch in, if needed. In my case, the "farm" is just 3 additional replicas that, at the beginning of the week, are identical to the other replicas and the design master. >Now, in Jet 4, data errors are just another form of conflict, so I >don't know if they are more easily resolved. > >But, either way, you're weakening the reliability of your data by >choosing to use replication outside its design parameters. Concur. Completely. Anybody who does this is on their own if things fall over. >> Usually, this is translated as LOSS OF DATA. Loss of data is >> definitely a BAD THING. [quoted text clipped - 4 lines] >is identical in all the replicas, and that means you can no longer >depend on the data. I don't disagree. If I ever was in that position, I know I would need to resurrect the prior replica set and then manually cull the new records from each of the newer replicas. Yes, I know that data edits would be lost unless I ran a compare against the prior replica set, field by field. Thankfully, my replica users primarily add new records, with very little editing of previous data. And even more thankfully, this has never happened to me. >Now, that's not corruption of the data in the conventional sense -- >what data is there remains accessible, but it's no longer >*trustworthy* data. Agreed. >And since you can't know for sure when this state is reached, that's >why the recommendation against using a setup that creates dead >replicas is so strong. I'm not sure I agree with this. You know you have reached this state when one of the replicas fails to replicate with another member. If that never happens, one never reaches this state. >> The solution is so simple (and has worked for me for over 4 years, >> with synchronization taking place weekly) that it boggles the mind [quoted text clipped - 4 lines] >Your solution doesn't sound simple to me. It has a number of steps >that have to be followed very carefully in order to avoid problems. Agreed. But like most things, the 10th time you do it, it is very little intellectual overhead, even though it still takes the same amount of time. >All this work, just to avoid paying for a dialup Internet account! Well, it is a bit more involved that just avoiding a dialup internet account, and I think you know that. If it were just that, then it would be internet replication and that is a technology that I don't think makes a lot of sense, personally. I'm reminded of the conversations that MichKa has had with folks when they complain about the condition that IIS must be left in (something about leaving the dropbox directory wide open) and other such things that turned me off to internet replication long ago. >> So, the question is how to go about not overburdening the replica >> set with dead replica information? Simple. Completely rebuild [quoted text clipped - 43 lines] >you just going to convince yourself that tables with the same >numbers of records actually contain identical data? I do not compare the data in every single field. I run the record counts and I also run enough numeric field summations to convince myself that the data has integrity from one week to the next. I've said this before (in messages many moons ago), but maybe it is just my schema that allows it to work for me and it will never work for anybody else. But it does work for me and after more than 4 years you would think I would find one record with wrong information on it if the darn thing was going to go sideways on me. What I mean by this is that, even after doing my double checks, you would think that I would discover a non-numeric field at some point (maybe weeks later) where things haven't gone properly. Thankfully, I haven't. And neither have those who are the users of the output from the .mdb file. Or I think I would have heard about it by now. >> 10) Synchronize both replicas to design master (twice), and >> resolve any conflicts. Synchronize the design master to both [quoted text clipped - 29 lines] >every field in every record is identical would actually assure you >that something hasn't gone wrong. I think you can reach a 99.99% confidence level with something less than verifying each and every field. But I concede the point, nonetheless. >And, frankly, if you have code that does that, then why not just >forget about starting over each round of synchs and simply mis-use [quoted text clipped - 19 lines] >But you don't really know how much data you've lost, because you >aren't really verifying that the data in your tables is identical. You misunderstand me. I'm saying if the number of records in those tables looks like they are continually building up, long before you have a problem with synchronization, rebuild the replica set from the ground up to ensure that you don't run into a problem. I'm not saying that once something fails to replicate then go about the above. >> In a perfect world (I've tried this before), the regulars in this >> newsgroup would engage in an even-handed discussion about the pros [quoted text clipped - 8 lines] >and your advice of how to work around the problems is not even >complete. Well, I understand your position and I think you understand mine. And I do concur that this mechanism is outside of that which replication was intended to cover. >My advice is to get the remote machines connected to the Internet, >at which point all sorts of benefits for synchronizing data become >available. I have a hard time imagining that this would be an >insurmountable hardship, since even dialup is sufficient for >indirect replication. But you have stated in many messages that indirect is a royal pain. I would not recommend that to anybody. >You, on the other hand, are recommending a method that you admit >takes you nearly an hour a week to keep running smoothly (that's >nearly 50 hours a year, which is not an insignificant amount of >money to me), as opposed to recommending spending a small amount of >money to get the remote machines connected to each other. Point taken. Definitely a choice. Thanks for the dialogue. mike [] >>I'm one of the regulars who will advise against what you're >>suggesting. [quoted text clipped - 28 lines] > believe, while an XP Pro machine can only accept a connection from > an XP Pro machine. Again, am I wrong on that? I'm not sure. I don't have any clients running WinXP with whom I have used remote desktop. I use VNC, instead, because for my work with these workstations, the client and I both need to be seeing the desktop at the same time. I'm not really recommending workstation-to-workstation connections (because there are so many downsides that this greatly limits the number of scenarios where it has any benefit), just pointing out the possibility. >>So, to me, it is no longer the case that it is too expensive or >>too difficult to run replication in its intended environment, or [quoted text clipped - 28 lines] > True. But since I am essentially rebuilding my replica set each > week, they aren't given the chance to corrupt. So far as you know. That is, you can't really say that all the replicas are identical until you check every field of every record in both replicas against each other. That is an unacceptable risk. But if you've already written the code to do this kind of check, well, good luck. >>But the main point of no return is when data errors prevent a >>successful synch. If the data error is in a dead replica, it is [quoted text clipped - 5 lines] > replicas that, at the beginning of the week, are identical to the > other replicas and the design master. Well, it's not a problem until it hits you. If you don't break the rules, you have vastly decreased the risk of the problem. >>Now, in Jet 4, data errors are just another form of conflict, so I >>don't know if they are more easily resolved. [quoted text clipped - 4 lines] > Concur. Completely. Anybody who does this is on their own if > things fall over. It's pretty clear to me at this point that you *do* understand the risks for yourself, so I'll stop ragging on *you* for using it yourself. ;) But I don't think you can count on that understanding in the people who might read your scenario. There are just too many steps that can't be automated, and that means human error creeps into the equation. Now, it's something I might try myself if I were doing it, but I'd never hand off the task to a client. Smart as my clients are, that would be putting too much trust in their infallibility. >>> Usually, this is translated as LOSS OF DATA. Loss of data is >>> definitely a BAD THING. [quoted text clipped - 12 lines] > primarily add new records, with very little editing of previous > data. And even more thankfully, this has never happened to me. Well, then, add the potential cost of recovering this added data from those replicas should your method fail. How many hours would *that* take? Add in also, the cost of the loss off edits, and I think that most clients would not be willing to spend their money that way. >>Now, that's not corruption of the data in the conventional sense >>-- what data is there remains accessible, but it's no longer [quoted text clipped - 9 lines] > state when one of the replicas fails to replicate with another > member. If that never happens, one never reaches this state. Not true. You *don't know* if problems are blocking full synchronization. It doesn't take a failed synch -- it only takes the errors (which can be generated in an otherwise successful synch). >>> The solution is so simple (and has worked for me for over 4 >>> years, with synchronization taking place weekly) that it boggles [quoted text clipped - 9 lines] > little intellectual overhead, even though it still takes the same > amount of time. Ah, familiarity of task makes it seem easy. That means your brain shuts off and you accidentally skip a step and end up losing your current synch data, and have to recover manually from the backups. Right? Factor in that cost. >>All this work, just to avoid paying for a dialup Internet account! > [quoted text clipped - 7 lines] > other such things that turned me off to internet replication long > ago. A dialup account enables indirect replication, not just Indirect (which I would never consider using for the reasons outlined above). The way to make indirect replication work over dialup Internet is to use a VPN connection to the server. These are now very easy to set up, even workstation-to-workstation (though the default security settings are poor). If you don't want to spring for the dialup Internet, then you can set up your server to accept dialin connections, and then the remote machines can connect that way. But if you're supporting very many users, you'd need to set up multiple dialin lines and that's expensive. That was a solution way back when, but I think very few companies now maintain their own dialin servers these days. Broadband and VPNs have made them pretty much obsolete. But they can still be a very good solution for connecting two PCs that have only dialup Internet access. [] >>> 9) Run a routine that attempts to give you confidence about >>> number of records in each table in the design master and the [quoted text clipped - 9 lines] > counts and I also run enough numeric field summations to convince > myself that the data has integrity from one week to the next. You've convinced yourself, but you haven't convinced me. Are you your own client here, or is this for a paying client? Are they aware of what you're doing here? > I've said this before (in messages many moons ago), but maybe it > is just my schema that allows it to work for me and it will never [quoted text clipped - 8 lines] > > Or I think I would have heard about it by now. I had a situation with a programming error in an application years ago that took nearly a year of daily use to be discovered, and then almost an entire year to diagnose and fix. And it was a case where data edits to the records were not getting saved -- but it happened very, very seldom, so it just wasn't noticed for a very long time. Once it was discovered, it was found that lots of people companywide had been noticing the discrepancies, but assumed it was their own bad memory, or mistaken entries. This taught me never to assume anything about the reliability of my code, nor about my ability or the ability of my users to notice errors. [] >>From my point of view, you're giving bad advice. You're telling >>someone to use replication in a manner that it wasn't designed [quoted text clipped - 4 lines] > And I do concur that this mechanism is outside of that which > replication was intended to cover. Well, I hope nobody follows your advice, since you're claiming no responsibility for whether or not it will work for them. >>My advice is to get the remote machines connected to the Internet, >>at which point all sorts of benefits for synchronizing data become [quoted text clipped - 4 lines] > But you have stated in many messages that indirect is a royal > pain. I would not recommend that to anybody. It's much less of a pain to keep running than the work you're doing to do your replication kludge. SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc <snipping time> >>>Well, broadband is a reality nowadays and WTS comes included in >>>all Windows servers, as well as being available on WinXP [quoted text clipped - 16 lines] >number of scenarios where it has any benefit), just pointing out the >possibility. OK. >> True. But since I am essentially rebuilding my replica set each >> week, they aren't given the chance to corrupt. [quoted text clipped - 9 lines] >But if you've already written the code to do this kind of check, >well, good luck. No, I have not. Never had the need. I know, I know... >>>But the main point of no return is when data errors prevent a >>>successful synch. If the data error is in a dead replica, it is [quoted text clipped - 7 lines] > >Well, it's not a problem until it hits you. Of course. >If you don't break the rules, you have vastly decreased the risk of >the problem. Theoretically, this statement is hard to argue with. However, I don't know how much less than zero problems in 4+ years I can go. >>>Now, in Jet 4, data errors are just another form of conflict, so I >>>don't know if they are more easily resolved. [quoted text clipped - 8 lines] >risks for yourself, so I'll stop ragging on *you* for using it >yourself. ;) Thanks. >But I don't think you can count on that understanding in the people >who might read your scenario. There are just too many steps that >can't be automated, and that means human error creeps into the >equation. Always a possibility. >Now, it's something I might try myself if I were doing it, but I'd >never hand off the task to a client. Smart as my clients are, that >would be putting too much trust in their infallibility. Agreed. >>>> Usually, this is translated as LOSS OF DATA. Loss of data is >>>> definitely a BAD THING. >>>And since you can't know for sure when this state is reached, >>>that's why the recommendation against using a setup that creates [quoted text clipped - 7 lines] >synchronization. It doesn't take a failed synch -- it only takes the >errors (which can be generated in an otherwise successful synch). Are those errors completely silent, or do they add a record to an MSys table here and there? >> ... But like most things, the 10th time you do it, it is very >> little intellectual overhead, even though it still takes the same [quoted text clipped - 7 lines] > >Right? Theoretically correct. Hasn't happened to me, yet, but then again, if it had, we wouldn't be having this discussion. >Factor in that cost. So far, zero. >A dialup account enables indirect replication, not just Indirect internet is what I understood you to mean with the last word of the above line. >(which I would never consider using for the reasons outlined above). >The way to make indirect replication work over dialup Internet is to >use a VPN connection to the server. These are now very easy to set >up, even workstation-to-workstation (though the default security >settings are poor). VPN's are getting easier all the time. But they still require a bit of setting up and sometimes that involves the dreaded folks from the IS department, and sometimes the purchase of a VPN client. They are typically less expensive than hardware routers, though, so if you find yourself with a hardware router that is unresponsive to the Microsoft VPN client, you will likely end up buying a VPN client rather than replacing your router. I will say this, if you have a working VPN and MOD, I see no reason why indirect shouldn't be tried first, long before attempting the scenario I describe. >> I do not compare the data in every single field. I run the record >> counts and I also run enough numeric field summations to convince >> myself that the data has integrity from one week to the next. > >You've convinced yourself, but you haven't convinced me. That's ok. >Are you your own client here, or is this for a paying client? Are >they aware of what you're doing here? My, myself and I. I wouldn't foist this on anybody else who wasn't taking full responsibility for it. If I didn't make this clear before, I apologize. [I thought I had.] I can only see it being applicable where there are significant barriers (in the mind of the individual making the decision, not in your mind, or in mine) to implementation via MOD, whether by IIS/internet or VPN/indirect. >I had a situation with a programming error in an application years >ago that took nearly a year of daily use to be discovered, and then [quoted text clipped - 8 lines] >code, nor about my ability or the ability of my users to notice >errors. Understood. Remember, I'm reviewing the newly input and edited data on a weekly basis, so I'm the one most likely to be suffering from the bad memory or mistaken entries. >>>From my point of view, you're giving bad advice. You're telling >>>someone to use replication in a manner that it wasn't designed >>>for, and your advice of how to work around the problems is not >>>even complete. I left this in just because I think readers of this thread deserve to hear this with every message they read, so if they choose my path, they have been warned and warned and warned...... >> Well, I understand your position and I think you understand mine. >> And I do concur that this mechanism is outside of that which >> replication was intended to cover. > >Well, I hope nobody follows your advice, since you're claiming no >responsibility for whether or not it will work for them. Truth be told, nobody claims any responsibility for whether anything posted in a newsgroup will work. How many times have questions been put to MichKa regarding one or more of his unsupported (yet clearly phenomenal) helper applications only to find that nobody else can help and he doesn't want to set a precedent by offering support? You pays your money and you takes your chances. >>>My advice is to get the remote machines connected to the Internet, >>>at which point all sorts of benefits for synchronizing data become [quoted text clipped - 7 lines] >It's much less of a pain to keep running than the work you're doing >to do your replication kludge. We can certainly agree to disagree on that one, based on my results to date. mike [] >>>>And since you can't know for sure when this state is reached, >>>>that's why the recommendation against using a setup that creates [quoted text clipped - 11 lines] > Are those errors completely silent, or do they add a record to an > MSys table here and there? No, there will be an error record in one or more of the relevant system tables. >>> ... But like most things, the 10th time you do it, it is very >>> little intellectual overhead, even though it still takes the [quoted text clipped - 14 lines] > > So far, zero. Well, so far, funeral expenses for me personally are zero, but that doesn't mean I don't know that those expenses will, indeed, one day be incurred, and prepare for them accordingly. >>A dialup account enables indirect replication, not just Indirect > > internet is what I understood you to mean with the last word of > the above line. No, Internet replication and indirect replication are two completely distinct replication methods. The latter was not designed to run over the Internet, but on an SMB network connection. I used direct dialup for this in the past. Nowadays, I use a VPN connection across the Internet to do indirect replication, because the VPN provides with an SMB network connectiong inside the VPN tunnel. >>(which I would never consider using for the reasons outlined >>above). The way to make indirect replication work over dialup [quoted text clipped - 6 lines] > from the IS department, and sometimes the purchase of a VPN > client. . . . If you've got an IT department to work with, I'd say it's usually easier than when you don't. Indeed, I hardly ever encounter any organization with a dedicated IT person that doesn't already have a VPN in place. > . . . They are typically less expensive than hardware routers, > though, so if you find yourself with a hardware router that is > unresponsive to the Microsoft VPN client, you will likely end up > buying a VPN client rather than replacing your router. . . . Well, most organizations that have a VPN in place will provide a client to the end users who have a need to use that VPN, so I just don't see the issue here. > . . . I will say > this, if you have a working VPN and MOD, I see no reason why > indirect shouldn't be tried first, long before attempting the > scenario I describe. And I'm saying that even in a small office scenario where there isn't an existing VPN, that the difficulty of setting up the VPN is actually quite small, even workstation-to-workstation. Now, it's a little harder to properly secure such a connection (because the default MS VPN client/server setup uses non-secure protocols), but it's still not a huge obstacle. And the setup is a one-time expense, as is the setup of the indirect replication infrastructure. [] >>Are you your own client here, or is this for a paying client? Are >>they aware of what you're doing here? [quoted text clipped - 6 lines] > mine) to implementation via MOD, whether by IIS/internet or > VPN/indirect. In all the back and forth I'd lost track of that fact. I'm glad you re-iterate it here for the benefit of those who encounter this discussion in the Google archives. [] >>>>From my point of view, you're giving bad advice. You're telling >>>>someone to use replication in a manner that it wasn't designed [quoted text clipped - 4 lines] > to hear this with every message they read, so if they choose my > path, they have been warned and warned and warned...... Admirable of you. I just thought there was quite a bit of belligerence in your original post, in anticipation of someone like me disputing you. Turns out you're more reasonable and level-headed than my reading of the "belligerence" suggested to me at the beginning of the discussion. SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc I have been reading your dialog. These issues of dead replicas may be causing some of the security settings not to work properly in the replicated database. Currently, I copy the replica to my system, then sync the database and then copy the replica back to his machine via a memory key or ftp transfer to a server and then to his machine. I have a replicated database on a laptob that is connected to the internet via a cable modem at a clients home. How can one sync the database for design changes accross the internet via VPN without having a perament IP address? > [] > [quoted text clipped - 130 lines] > the "belligerence" suggested to me at the beginning of the > discussion. =?Utf-8?B?RnJhbmsgTWFuc2ZpZWxk?= <FrankMansfield@discussions.microsoft.com> wrote in news:2AA43249-84EA-49B1-AB7D-17884760E0BE@microsoft.com: > I have been reading your dialog. These issues of dead replicas may > be causing some of the security settings not to work properly in [quoted text clipped - 3 lines] > and then copy the replica back to his machine via a memory key or > ftp transfer to a server and then to his machine. This is a very, very bad thing -- very dangerous to the long-term integrity of your database. > I have a replicated database on a laptob that is connected to the > internet via a cable modem at a clients home. How can one sync the > database for design changes accross the internet via VPN without > having a perament IP address? If your design changes are for forms/reports, forget about it -- split the database and replicate only data. When the other end doesn't have a fixed IP address, there are a couple of workarounds: 1. call the person on the other end and have her check the IP address by going to http://WhatIsMyIP.com OR 2. use a Dynamic DNS service. The way this works is the machine on the other end runs a process that periodically connects to the dyamic DNS service and says "Hi! I'm [the name of your host] and this is my IP address." The dynamic DNS service then updates its DNS server to point to that IP address. Usually you end up with a host name like xxx.DynamicDNS.com, where xxx is a name you choose for yoursel, and DynamicDNS.com is the domain of your dynamic DNS service. When you request a connection to xxx.DynamicDNS.com, DynamicDNS.com's DNS server hands out the last IP address the process running on the computer with the dynamic IP address gave to it (it could conceivably be wrong, if the IP changed after the last update, so the update interval has to be fairly short, like 15 minutes). OR 3. assume the IP address hasn't change, and do #1 only if you can't connect to the last IP you used. Most broadband providers don't change your IP address often (my RoadRunner IP has been the same for nearly 18 months). Now, once you've got the IP address, and both ends are set up to initiate a VPN tunnel, you want to make sure you don't attempt direct replication over it. That means you can't use the Access user interface to do it -- you must have Replication Manager and the tools that come with it to do indirect replication. SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.