DIRECT Replica connection questions

[sturgel]

Hi all, I been reading up on this but I can't seem to confirm when a replica connects to another replica. What I mean by that is, does a replica test other replica connections when its setup for direct synchronization? Say whenever you open the replica database? Does it need to have access to the replicas in its set everytime you open it?

Here is what I am assuming and I would like someone to verify my assumptions for me if you can. When you do synchronization the default is direct synchronization because there is no setup. Indirect requires setup, Internet requires setup. So if you have a replica set that you are careful in direct synchronizing only when you are connected to the LAN network, then in theory the replicas can be used independently on the road, in the office, disconnected from each other, be brought back into the office, connected to the LAN and synchronized with no problems. Is that correct? The replicas only "know" about each other when they want to synchronize. And in direct synchronizing, the onus is on the user/code to initiate it. Does this sound right?

If you do a synchronization with one or more replicas not able to connect, the replica that can't be connected, is abandoned and removed from the replica set and its not easy to get it back into the replica set and synch again. Is that correct?

Please let me know if I am wrong!

One more thing, how do I get notified of a reply? On another site i never did get notified and found out there were answers there after the fact.
Thanks!

 

[sturgel]

I think I have my questions answered with a little digging. If not please let me know.

For anybody else here is an excellent thread to read "Setting up for Replication [edit: direct replication for laptops and tablet pcs]" http://www.access-programmers.co.uk/forums/showthread.php?p=900345#post900345

There are many little gems of advices, code, and steps to follow. Hopefully this will help you as it helped me!

Thanks!

 

[dfenton]

Hi all, I been reading up on this but I can't seem to confirm when a replica connects to another replica. What I mean by that is, does a replica test other replica connections when its setup for direct synchronization?

No, a synch does not ping the other replicas. In a direct synch, you specify the remote replica, and your local instance of Jet (running in your computer's RAM) pulls that remote replica's data across the network into its RAM and performs the synch (likely using temp files on the hard drive of your PC).

Every replica is known to every other replica via records in the MSysReplicas system table. That is, if Replica A synchs with Replica B and then Replica B synchs with C, Replica B will know about A and C and Replica C will know about A and B. Replica A will learn about Replica C if Replica B synchs with A after synching with C (or if C synchs direct with A).

MSysReplicas is global for all the replicas that existed at the time of the last synch with another replica.

Of course, all of that is ignoring local and anonymous replicas, which should be avoided entirely, as they make it way too easy to lose data (since they can only synch with a single parent replica, if that parent replica is lost, these local and anonymous child replicas are permanently cut off from synching with the rest of the replica set).

Say whenever you open the replica database? Does it need to have access to the replicas in its set everytime you open it?

It doesn't need access to any other replicas until the point at which you want to synch, and then it needs access only to the partner replica in the synch.

...if you have a replica set that you are careful in direct synchronizing only when you are connected to the LAN network, then in theory the replicas can be used independently on the road, in the office, disconnected from each other, be brought back into the office, connected to the LAN and synchronized with no problems. Is that correct?

Yes. I'm having a hard time conceiving of what is prompting the question, as this should all be obvious from all of the Jet replication documentation.

The replicas only "know" about each other when they want to synchronize.

Depends on your definition of "know". All replicas have a replica in the MSysReplicas system table, but different replicas might have different lists of replicas because of which replicas they and their partners have synched with.

And in direct synchronizing, the onus is on the user/code to initiate it. Does this sound right?

Synchronization never happens spontaneously.

If you do a synchronization with one or more replicas not able to connect, the replica that can't be connected, is abandoned and removed from the replica set and its not easy to get it back into the replica set and synch again. Is that correct?

The first part is correct, but getting it back in the replica set is as easy as opening the orphaned replica and synching with any partner in the replica set.

But you'd want to avoid situations where that happens, as it could theoretically lose data.

 

[sturgel]

Thanks David for taking the time to answer my questions. I really appreciate the effort and I do understand where you are coming from. The problem is, Microsoft has some confusing statements about replication that stumped me. Namely, to do replication on a laptop, the best choice is indirect replication. But I couldn't see how direct replication couldn't be used. So I need clarification. Thanks!

Of course, all of that is ignoring local and anonymous replicas, which should be avoided entirely, as they make it way too easy to lose data (since they can only synch with a single parent replica, if that parent replica is lost, these local and anonymous child replicas are permanently cut off from synching with the rest of the replica set).

Here is another gray area for me in terms of direct synchronization, local vs ? replicas. How is one local and what is the other form?

It doesn't need access to any other replicas until the point at which you want to synch, and then it needs access only to the partner replica in the synch.

I understand and I thought that was the case. When you say partner replica, what do you mean by that, any replica in the set? I'm using the star topology with a HUB as the main replica, should I create the replica from the HUB or copy the replica created for the LAN users?

Yes. I'm having a hard time conceiving of what is prompting the question, as this should all be obvious from all of the Jet replication documentation.

You can blame that on the conflicting Microsoft statements (use indirect for laptop use, no mention of direct synchronization which is much simpler and faster to implement in a LAN network environment)

Synchronization never happens spontaneously.

Replication Manager doesn't do auto synchs?

The first part is correct, but getting it back in the replica set is as easy as opening the orphaned replica and synching with any partner in the replica set.

I never knew that and can't recall reading it except that Microsoft mentions that the replica is removed from the replica set. Then I came across the knowledgebase article to recover a non-member replica so I was under the impression that this was what had to be done to get the replica back in the replica set.

David, thanks again for your time!

 

[dfenton]

The problem is, Microsoft has some confusing statements about replication that stumped me.

You might want to check the Jet Replication Wiki's article on things not to believe in the MS documentation (it's linked from the front page, http://dfenton.com/DFA/Replication/).

Namely, to do replication on a laptop, the best choice is indirect replication. But I couldn't see how direct replication couldn't be used. So I need clarification.

Please provide a citation for that, i.e., where the docs suggest that indirect is the best choice. I expect there's context that makes it clear why they seem to be pushing that.

Indirect replication has the advantage of being safe in all these scenarios:

1. synch across a wired LAN

2. synch across a WiFi connection

3. synch across the Internet

...whereas direct synch is only safe in the first case.

Here is another gray area for me in terms of direct synchronization, local vs ? replicas. How is one local and what is the other form?

The only type of replicas you should consider are global full replicas and global partial replicas (and I'm no promoter of partial replicas -- I think it adds a level of difficulty that is not worth the benefit). Local and anonymous replicas should be completely avoided, as they are very easy to invalidate should their parent replicas be lost. Michael Kaplan explains it here:

http://trigeminal.com/usenet/usenet027.asp?1033

Local and anonymous replicas can be created only via code, so if you're not using code to create your replicas, don't worry about it. In other words, you won't get a local or anonymous replica by accident.

When you say partner replica, what do you mean by that, any replica in the set? I'm using the star topology with a HUB as the main replica, should I create the replica from the HUB or copy the replica created for the LAN users?

By partner replica, I mean the replica you tell your replica to synch with. The file you declare as the partner replica might be non-replicated, or not a member of the same replica set. If either of those is the case, you'll get an error. But if the partner replica is a member of the same replica set, the synch will take place (barring any unforeseen error conditions that might prevent a synch). The only exceptions to the "any replica can synch with any other replica that is a member of the same replica set" rule are the local and anonymous replicas, which can only synch with their parent replica. This is seen as an advantage, since it's the reason they were created, but to me that's a fatal flaw, because it means any data in them can very, very easily get orphaned and not be synchronizable with the rest of the replica set.

Whether or not you create the replicas explicitly or just by copying depends entirely on what you want to do in regard to replica priority:

1. if you copy with the file system, all replicas will have the same priority.

2. if you create them through the Access UI or with a simple DAO command, the new replicas will have a priority 90% that of the parent replica.

3. if you use code to create the replicas, you can specify the precise priority you'd like, any arbitrary value between 0 and 100.

You can blame that on the conflicting Microsoft statements (use indirect for laptop use, no mention of direct synchronization which is much simpler and faster to implement in a LAN network environment)

I'd like to know what documentation you're referring to here so that I can add it to the Wiki article on "things not to believe in the MS documentation."

Synchronization never happens spontaneously.

Replication Manager doesn't do auto synchs?

Replication Manager doesn't do anything at all. It's nothing but a (bad) GUI for managing and configuring replication. I don't use it at all.

Now, "automatic synchs" can happen if you've set up scheduled synchs and the relevant synchronizer(s) have to be running. But it doesn't just start up by itself.

getting [a deleted replica] back in the replica set is as easy as opening the orphaned replica and synching with any partner in the replica set.

I never knew that and can't recall reading it except that Microsoft mentions that the replica is removed from the replica set.

Well, in general, when you choose to remove a replica from a replica set, it's usually because it really has been lost. But if there's some temporary condition that causes replication to think it's been lost (such as you temporarily changed the file name for some reason and forgot to change it back), you need do nothing but synch back with the replica set.

Then I came across the knowledgebase article to recover a non-member replica so I was under the impression that this was what had to be done to get the replica back in the replica set.

I'm not at all sure what that article (http://support.microsoft.com/kb/158936) means by the phrase "if the ReplicaID property of a replicated database becomes invalid". Perhaps it's true that once a replica is deleted from the replica set, it can't be synched back unless the ReplicaID is changed. All you'd have to do is one of these two things:

1. rename the deleted Replica. Open it in the Access UI. This will generate a new ReplicaID associated with the new file name. If you want your revived previously-deleted replica to have the same original name, close it and rename it back to the original name. Open it in the Access UI. This will generate another ReplicaID associated with the file name it has now. You will also have a "dead replica" in this replica's MSysReplicas table, i.e., the ReplicaID/filename pair you created in the first step. To clear that out, try synching with that changed filename, and it will be deleted. At this point, from this replica, synch with the original replica set. The replica will be seen as a new valid replica, not as the deleted replica, because even though it has the same filename in the same location as the replica that was deleted, it has a different ReplicaID, so as far as Jet is concerned, it's a completely unknown replica that is a valid member of the replica set.

2. as an alternative, open the "deleted" replica, and create a new replica. That new replica will be able to synch with the replica set without any problems. Of course, you have two replicas sitting around, and you might want to restore the original file name. In that case, you'll have to delete the original replica, attempt a synch with it from the new replica (to delete it), then rename the new replica back to the original name. To delete the ReplicaID associated with the other filename, just synch with it again. At that point, you have a new replica under the original filename with a new ReplicaID and should be able to synch back with the replica set (as described above in #1).

I don't see why anyone would bother with #2 when you have to do just as much renaming and deleting and synching while also adding the extra step of creating a new replica. Also, it has the disadvantage that the new replica would have a lower replica priority unless you create it in code and set the replica priority explicitly.

 

[sturgel]

Thanks again David for taking the time to clarify this for me. Can I suggest that simple laptop scenarios should be explained in your wiki? The time you took to explain all this to me would surely help others if it was outlined in your wiki. Now given the slow death the this version of replication is going through, it might be a mute point in the near future. But you are a better judgement of that!

Please provide a citation for that, i.e., where the docs suggest that indirect is the best choice. I expect there's context that makes it clear why they seem to be pushing that.

Here is the page I am talking about:
http://office.microsoft.com/en-us/access/HP052623361033.aspx

This page also states under direct synch that the replica will be removed if you synch and the replica can't be found. Hence the prior discussions.

Indirect replication has the advantage of being safe in all these scenarios:
...whereas direct synch is only safe in the first case.

Yes, I can see that, but I think it needs to be said in the wiki that direct synch is also a good choice for laptop situations where you normally connects to a wired LAN network but you also use the laptop on the road disconnected from the LAN, as wired implies always connected?

The only type of replicas you should consider are global full replicas and global partial replicas [/QUOTE

Local and anonymous replicas can be created only via code[/QUOTE
I can assume then that the type of replicas are global full/partial and local and anonimous full/partial replicas. Just 6 types.

By partner replica, I mean the replica you tell your replica to synch with.

Any replica in the replica set then but it has to be in the replica set.

Well, in general, when you choose to remove a replica from a replica set, it's usually because it really has been lost.

When is it really lost?

I'm not at all sure what that article (http://support.microsoft.com/kb/158936) means by the phrase "if the ReplicaID property of a replicated database becomes invalid". Perhaps it's true that once a replica is deleted from the replica set, it can't be synched back unless the ReplicaID is changed. All you'd have to do is one of these two things:

Another good section for the wiki.

Thanks again David!

 

[dfenton]

Thanks again David for taking the time to clarify this for me. Can I suggest that simple laptop scenarios should be explained in your wiki?

The point of a wiki is collaboration. Why don't you sign up for the Jet Replication Wiki and start an article somewhere and I'll collaborate with you on working it up. Feel free to cut and paste anything I've said in this thread into the Wiki.

The time you took to explain all this to me would surely help others if it was outlined in your wiki. Now given the slow death the this version of replication is going through, it might be a mute point in the near future. But you are a better judgement of that!

I think Jet replication is going to be around for a while precisely because Jet 4 is so widely available (in every version of Windows starting with 2000).

Here is the page I am talking about:
http://office.microsoft.com/en-us/access/HP052623361033.aspx

Already addressed in the Replication Myths page on the Wiki:

http://dfenton.com/DFA/Replication/index.php?title=Replication_Myths

It's #1 under "outright errors."

This page also states under direct synch that the replica will be removed if you synch and the replica can't be found. Hence the prior discussions.

Well, perhaps you're interpreting that too broadly. If you can connect to the remote location and the sought-after replica is not there, it will be removed from the replica set, because it really isn't there any more.

But a mere failure to access the machine or the folder that the replica as in will *not* remove it from the replica set. If you try to connect to \\Server\Databases\MyReplica.mdb and you can't connect to \\Server or there is no share called Databases, the replica won't be deleted. It's only if you *can* connect to \\Server and *can* browse the Databases share that the replica will be deleted *if* it's not found there.

Indirect replication has the advantage of being safe in all these scenarios:
...whereas direct synch is only safe in the first case.

Yes, I can see that, but I think it needs to be said in the wiki that direct synch is also a good choice for laptop situations where you normally connects to a wired LAN network but you also use the laptop on the road disconnected from the LAN, as wired implies always connected?

If you want it in the Wiki, put it there.

The only type of replicas you should consider are global full replicas and global partial replicas
Local and anonymous replicas can be created only via code

I can assume then that the type of replicas are global full/partial and local and anonimous full/partial replicas. Just 6 types.

I wouldn't know how local and anonymous replicas relate to the full/partial issue -- I have never consider it worth wasting my time to figure out.

By partner replica, I mean the replica you tell your replica to synch with.

Any replica in the replica set then but it has to be in the replica set.

The only replicas any replica is able to synch with are members of its own replica set, so I think this goes without saying. The idea that a replica could synch with a file that is not part of its replica set is nonsensical on the face of it.

Well, in general, when you choose to remove a replica from a replica set, it's usually because it really has been lost.

When is it really lost?

Well, the most common scenario would be when a replica has become corrupted and can no longer synch. In that case, you must remove it from the replica set and replace it with a new replica.

Also common are the dreaded "dead replicas," which are created by abusing Jet replication. Cleaning up those dead replicas is one of the main reasons you'd be deleting replicas from your replica set.

It's not something that happens accidentally. If the replica is there in an accessible location, it won't be deleted. If it's not accessible, it won't be deleted. It's only when the replica's location is fully accessible and the replica is not found there that it will be deleted.

Another good section for the wiki.

If you want to see something in the Jet Replication Wiki, put it there.