 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Replication / July 2006Database Loses Replication
The other forum couldn't answer this so I try here. Some background 1 master held locally (~72 MB) 15 replicas sitting on multiple data servers across country Data only, front end files are separate All MDB files are Access 2000 I use Access 2003 VBA used to replicate all databases nightly (or when ever I allow* it to run). *read as remember On occasion a mdb will corrupt. My procedure is to copy a new replica to the server under a different name and re-link the front end file for the users. Then taking the corrupt file, back it up a few times, compact/repair it and then sync it with the master. Make sense? Yes I know it is clumsy and I should be using a SQL Server but …. Yea well….lets not get into that. Don’t laugh at me. I tried to tell them…but noooo…what? Oh sorry… Here is the problem: Sometimes when I compact a corrupt database it is no longer a replica. It just becomes a normal database file. The first time this happened my partner didn’t notice it and put the repaired non replicable copy back into production and it created a whole lot of mess. I did notice that there is file create called ‘~TmpRpRc.mdb’ every time I try and compact the corrupt file. This file is actually a repaired copy of the database with the replication properties in tacked, which I can then use to replicate into the master. My question is why does the corrupted db lose its replication properties? And a tmp file created? And why did my sock suddenly sport a green strip? Is there a way to compact a corrupt file without removing the replication? Any comments are appreciated. Thanks. CAP After reading through a couple of posts it looks like your going to suggest Terminal Services. I am going to check on that but I doubt it will be available, thanks in advance. > The other forum couldn't answer this so I try here. > [quoted text clipped - 13 lines] > end file for the users. Then taking the corrupt file, back it up a > few times, compact/repair it and then sync it with the master. No, this is not the right way to do it. You should instead use the MOVE REPLICA function to move the corrupted replica (if that's possible -- once it's lost replicability, that may not work; I dunno about that, as I've never tried it), then create a new replica from one of the existing replicas. > Make sense? Yes I know it is clumsy and I should be using a SQL > Server . . . Um, why? > . . . but > ?. Yea well?.lets not get into that. Don?t laugh at me. I tried to > tell them?but noooo?what? Oh sorry? There's nothing wrong with Jet replication. Having SQL Server running on a bunch of laptops and trying to use SQL Server replication would cause you far more problems than Jet replication does. > Here is the problem: > Sometimes when I compact a corrupt database it is no longer a > replica. . . . This is a very common occurrence. > . . . It > just becomes a normal database file. The first time this happened [quoted text clipped - 5 lines] > repaired copy of the database with the replication properties in > tacked, which I can then use to replicate into the master. I don't know about that. Are you using code to compact the database, using a buffer file name, or opening it in Access and compacting from the menu? If so, that usual temp name is dbX.mdb where X is a number from 1 to N. > My question is why does the corrupted db lose its replication > properties? There is some kind of corruption in the headers of the file, and the replicability properties seem to be the most fragile. I've experienced this over the years and it's quite frustrating. The real answer is to eliminate whatever problem is leading to corruption. > And a tmp file created? . . . I don't know about the tmp file, to be honest. I've never seen that. But I don't use replication in any of my A2K3 projects. > . . . And why did my sock suddenly sport a green strip? Is > there a way to compact a corrupt file without removing the > replication? That's not under your control. > Any comments are appreciated. Thanks. > [quoted text clipped - 3 lines] > to suggest Terminal Services. I am going to check on that but I > doubt it will be available, thanks in advance. If you've got an infrastructure of servers in place, and there are fixed offices, I don't see why WTS would *not* be a better solution. It would eliminate any need for replication at all and make deployment and administration substantially easier. One issue that occurs to me now is this: are you doing direct replication across a WAN? If so, that's a probably cause of the corruption, and you shouldn't be doing it.  SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > > The other forum couldn't answer this so I try here. > > [quoted text clipped - 21 lines] > tried it), then create a new replica from one of the existing > replicas. I'm not familiar with the MOVE REPLICA function and a quick search here didn't give me any answers ( I will have to look deeper). The problem is that the users are making changes to all the replicas so if it becomes corrupt and none replicable I lose all the edits and additions to the database. Creating another replica from the design will only get me to the last days work. > > Make sense? Yes I know it is clumsy and I should be using a SQL > > Server . . . > > Um, why? Because I have way too many users (500+) all trying to edit and lookup data at the same time over too many replicated database. One or two SQL servers could solve the issue, not really the point though. > > . . . but > > ?. Yea well?.lets not get into that. Don?t laugh at me. I tried to [quoted text clipped - 4 lines] > replication would cause you far more problems than Jet replication > does. No laptops, all stationary desktops. Would be a VB or Web front end with SQL backend. > > Here is the problem: > > Sometimes when I compact a corrupt database it is no longer a > > replica. . . . > > This is a very common occurrence. You can say that again. > > . . . It > > just becomes a normal database file. The first time this happened [quoted text clipped - 10 lines] > from the menu? If so, that usual temp name is dbX.mdb where X is a > number from 1 to N. I am opening Access to compact and repaire the file. I haven't changed any buffer file settings that I am aware of. The dbx.mdb file is created in the process but this other file is also created once the compact is completed leaving me with a ~TmpRpRc.mdb file that is a replica and a second file with my orginal file name that is not a replica (the dbx.mdb is removed like normal). > > My question is why does the corrupted db lose its replication > > properties? [quoted text clipped - 33 lines] > replication across a WAN? If so, that's a probably cause of the > corruption, and you shouldn't be doing it. A better solution? Yes it would be. But we are talking 500+ machines to install the client on, if it doesn't exist, and licencing (although that may be taken care of already). I am looking into it but I don't think that the corp will be too pleased with that many terminal connections to their data servers. It is replication across a WAN during closed office hours, I know it isn't the best solution but at the time it is the only one. Thank you for your time and thoughts on this. >> > The other forum couldn't answer this so I try here. >> > [quoted text clipped - 29 lines] > the edits and additions to the database. Creating another replica > from the design will only get me to the last days work. Once a replica has lost replicability, it's no longer a replica, so MOVE REPLICA probably won't work any longer. But creating a replacement for it should be done by creating a new replica in place from an existing replica, not by copying an old replica over top of the old one. And it's important that you delete the corrupted replica from the replica set by attempting a synch with it after you've moved it. Otherwise, you'll have multiple replicas with the same name, but different replica IDs. As to your last sentence "Creating another replica from the design" I didn't say using the design master to create the new replica. You can use the last replica to synch with the corrupted one. You're going to lose the data until you recover it manually from the replica that lost replicability either way -- the only issue is how you create the replacement replica. A replica farm would solve this problem, seems to me: http://trigeminal.com/usenet/usenet006.asp?1033 >> > Make sense? Yes I know it is clumsy and I should be using a SQL >> > Server . . . [quoted text clipped - 5 lines] > One or two SQL servers could solve the issue, not really the point > though. Ah, yes, that's true. But if you're contemplating replicating with SQL Server, you're asking for problems. You'd want a single SQL Server serving all your users. That may or may not be feasible given your WAN topology. >> > . . . but >> > ?. Yea well?.lets not get into that. Don?t laugh at me. I tried [quoted text clipped - 7 lines] > No laptops, all stationary desktops. Would be a VB or Web front > end with SQL backend. There's no reason to abandon your Access front end just because you move to a SQL Server back end. That would be enormously foolish and horridly expensive. >> > Here is the problem: >> > Sometimes when I compact a corrupt database it is no longer a [quoted text clipped - 3 lines] > > You can say that again. But it is always caused by some failure *outside* of Access/Jet. Fix that failure, and the problem will go away. >> > . . . It >> > just becomes a normal database file. The first time this [quoted text clipped - 19 lines] > that is a replica and a second file with my orginal file name that > is not a replica (the dbx.mdb is removed like normal). I've never seen that, so can't explain it. It bothers me to be using replicas promiscuously because you can end up littering your replica list with dead replicas. >> > My question is why does the corrupted db lose its replication >> > properties? [quoted text clipped - 5 lines] >> The real answer is to eliminate whatever problem is leading to >> corruption. Let me stress that the sentence above is the most important thing in my post. The hard part is identifying the source of the corruption. [] >> > After reading through a couple of posts it looks like your >> > going to suggest Terminal Services. I am going to check on [quoted text clipped - 11 lines] > A better solution? Yes it would be. But we are talking 500+ > machines to install the client on, . . . *What* client? The remote desktop client is on all WinXP machines. And, of course, you already have installed *Access* on all these client PCs, and installing the RDP client is much simpler than installing Access! > . . . if it doesn't exist, and licencing (although that may > be taken care of already). . . . If Access is installed on the client workstations connecting to the terminal server, then all you need is the appropriate CALs for your Terminal Servers, which cost approximately $40 each, last I checked. THat's a lot with 500 users, but in terms of reduction in downtime and administrative costs, it would end up being a large savings, seems to em. > . . . I am looking into it but I don't think that the > corp will be too pleased with that many terminal connections to > their data servers. Er, a terminal server should be a dedicated box if it's serving any significant number of users. > It is replication across a WAN during closed office hours, I know > it isn't the best solution but at the time it is the only one. If it's direct replication across a WAN, then that's the source of all your problems, and you need to stop it if you want to solve the problems. You *must* use indirect replication when not synchronizing across a LAN. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Thank you very much for your time. I will take a look at my options and see if a terminal sever will work, as well as try to find a way to use indirect replication . I appreciate your help on this. Unless you have record locking off I don't see how you could corrupt via normal user input. Though I've heard there is an issue with the memo fields. As David said it's probably the direct replication over a WAN. It's a dangerous game. As a stop gap, you can back up that day's replica at the remote site before you synch. If you can run a batch file from your VB code that would be the fastest. Instruct people to contact you as soon as they open a corrupted replica the next day in case you don't catch it. Then just copy the previous evening's replica back over the bad one and continue on. We do something similar for our system backup. I wrote a small executable that creates a folder named using the current date. IE todays folder would be called 20060630. That way I have a backup folder with a bunch of date named folders that hold versions of files going back as long as I need. > Unless you have record locking off I don't see how you could > corrupt via normal user input. . . . Well, there are dozens of reasons why MDBs corrupt. It's quite common. Almost all of them are caused by software or hardware failures. Most people say it's hardware, but in my experience, it's almost always been software that's caused the corruption, instead. > . . . Though I've heard there is an issue with the > memo fields. . . . If a memo is being edited by a user in a bound form at the time a synch occurs with the back end, it can corrupt the memo pointer and cause the loss of the record that the memo belongs to. Because of this, memo fields in replicated dbs should always be edited unbound *if* synchs can ever happen while a user is editing a memo. > . . . As David said it's probably the direct replication over a > WAN. It's a dangerous game. As a stop gap, you can back up that [quoted text clipped - 3 lines] > next day in case you don't catch it. Then just copy the previous > evening's replica back over the bad one and continue on. No, no, no, no, no. If you have a replica farm, this is never necessary. The way that would work is that before the WAN synch, there's a synch to the replica farm. At that point, all the replicas in the replica farm have data indentical to the edited replica. Another way to avoid issues it so never synch remotely with anything but a replica other than the edited replica. I always use a hub replica for synching that is distinct from the replica that is used for edits. A synch between the edited replica and the hub replica happens before the synch with the remote replica. Of course, none of this can be done with direct replication, which is, in my opinion, the source of all the problems -- direct replication is not suitable for a WAN. > We do something similar for our system backup. I wrote a small > executable that creates a folder named using the current date. IE > todays folder would be called 20060630. That way I have a backup > folder with a bunch of date named folders that hold versions of > files going back as long as I need. This is ridiculous. You have replication in place. It's a piece of cake to synch with a backup MDB before your synch with the remote replica. That makes *much* more sense than doing a file system backup. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > Well, there are dozens of reasons why MDBs corrupt. It's quite > common. Almost all of them are caused by software or hardware > failures. Most people say it's hardware, but in my experience, it's > almost always been software that's caused the corruption, instead. > > . . . As David said it's probably the direct replication over a > > WAN. It's a dangerous game. As a stop gap, you can back up that [quoted text clipped - 20 lines] > is, in my opinion, the source of all the problems -- direct > replication is not suitable for a WAN. So you're saying, "There are dozens of reasons they corrrupt but direct replication is the source of all problems?" >From his original post he indicated that he has 15 distributed replicas. My guess is that they are all separated by a WAN and can't do local sychs with each other. The single replicas are his hub. Do you think if he created a separate hub (at each location) and it got currupted and then sych'd with the editing replica that the editing replica wouldn't get corrupted or lose data? > > We do something similar for our system backup. I wrote a small > > executable that creates a folder named using the current date. IE [quoted text clipped - 10 lines] > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ I would not rely on synch'ing to a back up file as a backup system. I don't place that much trust in the mechanism. Ridiculous is thinking you can't propogate corruptions and user error to a synch'd backup without realizing it until it's too late. >> Well, there are dozens of reasons why MDBs corrupt. It's quite >> common. Almost all of them are caused by software or hardware [quoted text clipped - 30 lines] > So you're saying, "There are dozens of reasons they corrrupt but > direct replication is the source of all problems?" No. Direct replication *OVER A WAN* is dangerous and can lead to corruption of the headers of an MDB. That kind of corruption (which can also be caused by dozens of other problems) leads very often to loss of replicability. I would say that it's likely that the exact cause of the corruption that loses to loss of replicability is the direct replication over a WAN -- one should never use direct replication except over a LAN (two issues, bandwidth and reliability of connectivity). >From his original post he indicated that he has 15 distributed > replicas. My guess is that they are all separated by a WAN and > can't do local sychs with each other. . . . And? > . . . The single replicas are his hub. Do you > think if he created a separate hub (at each location) and it got > currupted and then sych'd with the editing replica that the > editing replica wouldn't get corrupted or lose data? Yes, of course! Replication cannot "infect" another replica with corruption. I have never done indirect replication without having a hub replica for synching separate from the edited replica for the very reason that it's just *safer* not to be doing the remote synch on the production replica. Also, having a separate replica for synching requires that you synch the edited data with another replica before your synch with the remote replica, so the result is that you can never lose data. The hub replica + production replica architecture is the smallest possible replica farm, and provides one of the main advantages of the replica farm (backup). >> > We do something similar for our system backup. I wrote a small >> > executable that creates a folder named using the current date. [quoted text clipped - 11 lines] > is thinking you can't propogate corruptions and user error to a > synch'd backup without realizing it until it's too late. I would suggest that *you* stop using replication if you don't trust it. Backups to other replicas are unquestionably the safest and easiest backup for a replica set. The corruption that the user was having is *not* normal. I've seen it, yes, but it is not normal -- it's caused by something that needs to be fixed. Even so, corruption can't be spread through synchronization, so there's no danger in the setup I described, where your edited replica never synchs except with a local hub replica that is used for the remote synchs. That layer of protection would mean you'd never need to manually recover data if replicability was lost, because replicability would only be lost in the hub, and it is disposable, since it's just a duplicate of the data in the production replica. If you want to believe in voodoo, then I don't really think you should be using replication. I don't even think you should be using computers. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ What happens when there is a bad sector beneath your memo field and it scrambles the data? What happens when a user erases a bunch of records accidently? How does replication protect you against those sorts of errors? His orginal post reported that he was getting corruption errors due to some unknown reason. My suggestion was how to protect him from data loss using a simple backup system. Obviously it is unacceptable to you because it doesn't fit in the database schema of your existence. Sorry you are so intimidated about someone else helping out in your personal forum. I am not the god of Access but I have also written database programs (from scratch) and been programming for twenty years. There are many who are sharper than I. You must be one of them so I guess we can put this at rest. > What happens when there is a bad sector beneath your memo field > and it scrambles the data? . . . That can just as easily happen to your file-copy backup as to your replicated backup. This is one of the problems a replica farm solves. > . . . What happens when a user erases a bunch of records > accidently? . . . The same thing that happens when a user does the same thing in a non-replicated database. > . . . How does replication protect you against those sorts of > errors? . . . How does replication exacerbate them? It doesn't -- the problems are exactly the same with non-replicated databases, but with replication you have the additional problem of creating dead replicas if you open them in the wrong location. > . . . His orginal post reported that he was getting corruption > errors due to some unknown reason. My suggestion was how to > protect him from data loss using a simple backup system. Obviously > it is unacceptable to you because it doesn't fit in the database > schema of your existence. It's not *my* requirements but those of replication that file copying violates. In any event, synching with another local replica before initiating the remote synch that was (apparently) causing the corruption would have meant that he wouldn't have lost any data (i.e., wouldn't have to recover it manually from the replica that had lost replicability). > Sorry you are so intimidated about someone else helping out in > your personal forum. . . . Intimidated? No, I'm just pointing out that your advice has problems that are not present with a different kind of solution. > . . . I am not the god of Access but I have also written > database programs (from scratch) and been programming for twenty > years. There are many who are sharper than I. You must be one of > them so I guess we can put this at rest. Replication works the way it does. The result is that file copies for backups are dangerous in ways that they are not in non-replicated databases. I didn't make that up -- it's the way it is. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
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.