 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Replication / December 2006Planning for a corrupted hub replica in a star topography
Before I make the leap to include replication, I need a plan for what happens if the hub replica (located on a server) in a star topography gets corrupted. I'm only talking about back-end files (i.e. only tables). Here's how I think I could handle the situation: Make regular backups of the hub replica and place those backups in a backup folder on the server. Probably would be easiest to make replicas of the main hub replica since replicas can function as backups. Then if the main hub replica gets corrupted all an adminstrator has to do is to take the most recent main hub replica backup (really a replica itself) and use it. That way the backups are all from the same replica set. I need verification of this statement. Assuming that I never set the replication priority, I assume that when the main hub gets corrupted and a backup replica is then copied over the corrupted one, when synchronization occurs between the new hub replica and local copies, the new hub replica will be updated by the local copies as necessary and vice versa. It may take several cycles to make sure that every replica is updated. Of course this all depends on when the main hub became corrupted relative to the last time local copies were synchronized. Am I correct in this generalized statement? > Before I make the leap to include replication, I need a plan for > what happens if the hub replica (located on a server) in a star [quoted text clipped - 5 lines] > Make regular backups of the hub replica and place those backups in > a backup folder on the server. No, that's just silly. All replicas are backups of every other replica. After a synch, the two replicas that have synched are identical. That's the point of a replica farm, so I'd say that your best bet is to simply have multiple replicas on the server that are kept in synch on some kind of schedule. It can be done with a vbScript and the TSI Synchronizer, in fact, and then schedule the vbScript to run in the Windows Scheduler. > Probably would be easiest to make > replicas of the main hub replica since replicas can function as > backups. YES! > Then if the main hub replica gets corrupted all an > adminstrator has to do is to take the most recent main hub replica > backup (really a replica itself) and use it. NO, NO, NO. Instead, you first open one of the backup replicas, attempt to synch it with the corrupted replica (which deletes the corrupted replica from the replica set), then create a new replica to replace the old one (using the same name so it transparently replaces the lost replica). > That way the backups are > all from the same replica set. Well, yes. You don't want to copy things to backup directories and all of that, because to synch in place, you can't then copy them back to another location, unless you use the MOVE REPLICA command in ReplMan or the TSI Synchronizer (JRO does not provide access to this essential command, which is one reason why JRO is just a complete waste of time). > I need verification of this statement. Assuming that I never set > the replication priority, I assume that when the main hub gets > corrupted and a backup replica is then copied over the corrupted > one, No, no, no. Never copy over top of anything. If a replica is lost, rename it. Then attempt to synch with it from another OK replica. That will delete the corrupt replica from the replica set. Then synch around the replica set to tell all the replicas that the old replica is gone. Then create a new replica in the location of the lost one with the same name as the lost one had before. > when > synchronization occurs between the new hub replica and local [quoted text clipped - 4 lines] > copies were synchronized. Am I correct in this generalized > statement? I've never had any corrupted replicas. I would recommend that if you have make a distinction between your replica that functions as the hubs for synchronization and the replica that is used by the LAN-connected users for editing. That way, only the hub is exposed to the danger of direct synchs, and can be easily replaced.  SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Right. I forgot that you can't move replicas, so I can't just move a backup to replace the corrupted one. In another post, I note that my application uses data from multiple data sources, which do not talk to each other. Therefore, I do not allow any user (except myself) to open the back-end files directly. Everything must be done through the app user interface. Hence, I think I'll create a small app that will allow administrators to select the corrupt replica and a backup replica. Then I'll use the MakeNewReplica command to create a new hub replica from the backup. The code will Kill the old hub replica first (if it exists). Thanks. > > Before I make the leap to include replication, I need a plan for > > what happens if the hub replica (located on a server) in a star [quoted text clipped - 78 lines] > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ Here's the code I'm using to create a replica (error handling has not been included) Sub MakeNewReplica(strReplicableDB As String, strNewReplica As String) Dim dbs As DAO.Database, ws As DAO.Workspace Dim fso As Object Set fso = CreateObject("Scripting.FileSystemObject") If fso.FileExists(strNewReplica) = True Then Kill strNewReplica DoEvents End If Set ws = DBEngine(0) Set dbs = ws.OpenDatabase(strReplicableDB) dbs.MakeReplica strNewReplica, strReplicableDB dbs.Close Set dbs = Nothing Set fso = Nothing > Right. I forgot that you can't move replicas, so I can't just move a > backup to replace the corrupted one. [quoted text clipped - 92 lines] > > David W. Fenton http://www.dfenton.com/ > > usenet at dfenton dot com http://www.dfenton.com/DFA/ > Here's the code I'm using to create a replica (error handling has > not been included) [quoted text clipped - 19 lines] > Set dbs = Nothing > Set fso = Nothing Why do you need to do anything at all with the workspace? You are just using the default workspace, the same one being used in Access. You can do: Set dbs = OpenDatabase(strReplicableDB) without needing to do anything with the workspace. Also, if you're going to assign a workspace variable, you need to set it to Nothing at the end. You should also close the database that you opened, since it's not the CurrentDB. Last of all, you don't need to use the File System Object to check for the existence of the file, because you can't be running this code except when you're already connected to the server. You can use the Access Dir() command and check for whether it returns a string of Len()>0. And also you need to attempt the synch with the killed replica in order to remove it from the list of replicas in the replica set. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > In another post, I note that my application uses data from > multiple data sources, which do not talk to each other. [quoted text clipped - 5 lines] > create a new hub replica from the backup. The code will Kill the > old hub replica first (if it exists). You have to do more than that. You have to rename it or kill it first then attempt to synch with it (to delete it from the list of replicas), nnd only then should you create the replacement replica. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ You have to do more than that. You have to rename it or kill it > first then attempt to synch with it (to delete it from the list of > replicas), nnd only then should you create the replacement replica. Thanks, for the heads up, but I don't understand. If I kill it first, there's bound to be an error when I try to synch. So I guess you're saying that that error causes Jet to remove the defunct replica from the list, right? Can you point me to some code as I'm kind of fuzzy on the exact procedure. Also, I would want this entire process to be transparent to the user, so I imagine I'll be trapping errors or using On Error Resume Next. > > In another post, I note that my application uses data from > > multiple data sources, which do not talk to each other. [quoted text clipped - 13 lines] > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ > You have to do more than that. You have to rename it or kill it >> first then attempt to synch with it (to delete it from the list [quoted text clipped - 5 lines] > guess you're saying that that error causes Jet to remove the > defunct replica from the list, right? Yes. > Can you point me to some code as I'm kind of fuzzy on the exact > procedure. Also, I would want this entire process to be > transparent to the user, so I imagine I'll be trapping errors or > using On Error Resume Next. I don't have code for deleting a replica, but it ought to be pretty easy to find out the error number and using an error handler that simply ignores that particular error. Or, the easy way (which I don't recommend: put in On Error Resume Next before the synch command, and then On Error Resume 0 (or your error handler, if you have one) on the line after it. Of course, that will also ignore errors of other type, which I don't consider a good thing at all. But it *is* easy. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Does this problem apply when you're simply making a replica and replace an existing replica all in the same location. I could swear I've seen code or directions from Microsoft that does this. If your replacing an existing replica with another replica with the exact same name in the same location, I'm unclear on why this presents a problem. > > You have to do more than that. You have to rename it or kill it > >> first then attempt to synch with it (to delete it from the list [quoted text clipped - 25 lines] > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ BTW: How do I get my hands on the Jet Synchronizer? I'm going to give it a shot to see if IT will allow it to be installed, but I seriously doubt it. If so, then I'm definately going the indirect route. Also, is it possible that I could create my own synchronizing app in Access to mimic the Jet Synchronizer, or is this pretty much out of the question. rdem...@hotmail.com wrote: > Does this problem apply when you're simply making a replica and replace > an existing replica all in the same location. I could swear I've seen [quoted text clipped - 31 lines] > > David W. Fenton http://www.dfenton.com/ > > usenet at dfenton dot com http://www.dfenton.com/DFA/ No need to reply to this. I was able to download it on my personal machine at home. I also confirmed that the machines at work are not allowed to download it (i.e. you do not have adminstrative permissions error). > BTW: > [quoted text clipped - 42 lines] > > > David W. Fenton http://www.dfenton.com/ > > > usenet at dfenton dot com http://www.dfenton.com/DFA/ > How do I get my hands on the Jet Synchronizer? I'm going to give > it a shot to see if IT will allow it to be installed, but I > seriously doubt it. If so, then I'm definately going the indirect > route. I think I've posted this in this thread already, but here it is again (all on one line): http://groups.google.com/group/microsoft.public.access.replication/ms g/3b7167c1462b2d2f > Also, is it possible that I could create my own synchronizing app > in Access to mimic the Jet Synchronizer, or is this pretty much > out of the question. No, not really. You could manually program something like it, but Microsoft spent many man years developing replication. You can certainly create an app to do nearly everything that Replication Manager does, but you still need the synchronizer (which you can get through a link listed in the post listed above). SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > Does this problem apply when you're simply making a replica and > replace an existing replica all in the same location. I could > swear I've seen code or directions from Microsoft that does this. > If your replacing an existing replica with another replica with > the exact same name in the same location, I'm unclear on why this > presents a problem. You should never ever replace a replica with a new replica of the same name in the same location unless you've deleted the original one from the replica set. The reason is because it creates the dreaded "dead replica". See this explanation of what a "dead replica" is and what causes it (all on one line): http://groups.google.com/group/comp.databases.ms-access/msg/9f5a84194 fa6c653 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.