1. UNGODLY autonumber values such as -23432432334 which replication uses to do a 'hit and miss' to prevent duplication in a relational structure. A nightmare for any relational structure.
You mistake autonumber PKs for meaningful data. They are metadata, useful in the background, and if you care what the values are, you really don't understand their purpose.
So, this is *your* problem, not Jet replication's problem.
2. ANY loss of connection (or even the smallest hiccup) by an external user while updating data will lead to orphaned records.
Er, what? Do you mean a dropped connection during a direct synch? If so, then that's a problem with choosing an unreliable connection. If you mean regular editing, then that's a Jet problem, not a replication problem.
In any event, I've never seen an orphaned record in any replica set in the 13 years I've used Jet replication. I *have* seen errors/conflicts reported because of problems that led to referential integrity issues, but no data was ever corrupted and no data integrity was compromised. Yes, the problem has to be resolved in order for the data to get properly synched, but that's what you'd *want* to happen.
So, I think this one is complete malarkey, at least in the rather sketchy form in which the point is worded.
3. ANY loss of connection (or even the smallest hiccup) by an external user while synchranizing code will cause problems with the 'nodes' and possibly the master.
Synchronizing "code"? Who but those who don't know the rules of replication would synch anything other than pure Jet objects?
Further, this seems to me just a restatement of #2, i.e., using an unreliable connection for a direct synch can cause loss of data (or, at minimum, loss of replicability) if you have a dropped connection during the synch.
But that applies only to DIRECT SYNCHS, which are not recommended for any connection other than a wired LAN. There is no possibility of a loss of data or corruption if you use indirect or Internet synchronization.
So, if you tried ot use direct synchronization in unsuitable circumstances and lost data, then THAT IS YOUR FAULT -- you were doing it wrong by not following best practices for replication.
4. Replication is a hog when it comes to trying to synchranize thousands of records (or code) and hiccups are often regardless of good connections. (I wouldn't even trust it to syncrhanize a dozen non-relational records.) Users with fast internet connections were constantly complaining about hiccups and inaccurate data during synchranizing. I was constantly fixing problems with destroyed replicated mdb's for users.
An Internet connection is not a suitable connection for a direct synch. It is only suitable for an indirect or Internet synch, and in those latter two cases, it is impossible to lose or corrupt data.
So, again, this is YOUR ERROR. You were using the wrong synchronization methods.
5. If the 'master' becomes corrupt in any way (which happens often),
No, it doesn't happen often, unless you're being a fool and using your Design Master as part of your daily synchronization topology. The DM should be squirrelled away somewhere safe, never edited by users and should be synched only often enough to keep it from expiring (the default retention period for replicas created through the Access UI is 1000 days, through DAO code, 60 days).
I have recreated DMs, but never because it was corrupted during a synch. I've only done it to recover from unrecoverable replication errors (all of them that I can recall caused by my own mistakes, not by flaws in Jet replication).
a restore of the NON-replicated mdb will need to be done and re-creation of the master and nodes.
Recovering the DM does not require recreating the whole replica set. If you think that, then you really do not have any significant understanding of Jet replication.
It was actually the use of replication and the problems it presented that led to the downfall of the university of Milwaukee running the Midwest Renewable Energy Star program. I was then tasked to actually replace the replication schematic to develop a more reliable and accurate system for tracking the Renewable Energy program (since the error in totals stemming from the replication system were well above 10%).
I hate to be blunt, but Jet replication was not the cause of the problem -- it was the choice of a technology that was not understood by the people implementing it.
I don't mean to criticize your comments dfenton but saying someone needs to simply understand the basics of replication or that it runs smoothly and non-problematic is a vast understatement. Even understanding the basics (and advanced features as I did), it's a disaster of a product and one of MSAccess's worst features.
You have supplied nothing but examples of ignoring best practices and you're saying that the problems were inherent to Jet replication. They are not -- they are due to doing things wrong.
And best practices are easily figured out *if* you take the time to understand how Jet replication works. If you do that, you'd understand why direct replication is suitable only to wired LAN connections. You'd also understand that indirect/Internet replication can never corrupt replicas, because they never open the remote replica across the wire.
If you don't know these things, then you are a novice in regard to replication and shouldn't be making blanket assertions about whether it works or not. Everything you've described was YOUR OWN ERROR, not due to some inadequacies in Jet replication.
I strongly, strongly discourage it's use for anything!
I would also strongly discourage anyone as ignorant of Jet replication as you seem to be from using Jet replication.
However, anyone who is willing to take the time to learn and implement best practices should have very little problem setting up a reliable synchronization system.