对于这个问题感到有些疑惑，所以，以下发布的信息将给人们一个确切地解释，为什么做这项工作是一件糟糕的事。
让我从副本很酷说起。它让你做没有其他办法做的工作。该发布的信息不是要反对副本，它是反对那些想用未被设计的方法来使用它的人……并举出了许多理由，说明为什么他们所做的工作对他们的应用程序和数据来说是很危险的。
************************************
复制的目的：是为了获得Jet数据库的两个或更多的拷贝，这个数据库始终被认为是远离相同的一个同步 。多人可以在多数据库中进行转变，但最终每一个人都将达到“收敛”而且都将是相同的。这个支持是用于连接的和偶尔连接的用户的……但不用于断开用户的。Microsoft Jet复制不支持你没有正确的直接，间接，或因特网连接的方案。周期。
************************************
移动/拷贝后台：Microsoft Jet，任何时候它打开一个副本（用于同步，或你的app打开它，或无论什么）将会确定副本是否已被移动。它通过比较路径和机器做到这些。如果它确定其不在相同的位置上，它就会假设你已经拷贝了副本而且会基本上给该副本一个新的副本ID（对于有相同副本ID的两个副本来说，后果非常糟）。这样，如果你有四个副本的副本设置，你移动一个副本的位置然后打开它……Jet就会认为在副本设置中，你有五个副本。
这应用于以下的所有情况：
1) 移动副本到软盘，然后使用软盘，这样你就能够在所在目录或其他位置处理副本。
2) DOS或资源管理器中的直接文件移动/拷贝
3) 通过zip盘移动副本，你就可以通过两个不同的机器/路径处理它……除非机器名和路径是相同的，它将被 Jet认为是“拷贝”的，虽然你把它留在zip盘上并从那儿同步。
4) 给其他人发副本
5) 用任何你想到的其他办法来拷贝，从因特网站点或文件服务器共享等下载。
以下情况不适用：
1) 使用内部方法来移动副本，通过复制管理器菜单命令或TSI同步装置移动复制（MoveReplica）方法。
2) 公文包协调器
现在，这些行为会产生一个错误，一个烦恼，和三个设计问题，它们是真正的错误，并能够导致损坏和/或数据丢失。
************************************
错误 #1：在Jet处理该“改变副本ID”资料中存在单个独立错误……它不会清除关于同步装置管理的指定副本的信息。因此，如果你使用Jet同步装置进行因特网/间接复制，而且，你拷贝其他位置的一个被管理的副本，Jet将会使它成为新的副本，但仍会认为旧的同步装置在管理着它。如果不是，那么，当你以后要进行同步时，就会出现问题。如果它是一个非管理的副本，你就不会遇上任何问题。这已被Microsoft内部证实存在问题，但因为这个方案不被支持，在服务发布中的风险修复就不会被认为是重要的。工作区是非管理的，或以合法方式创建新副本，这样，你就会有非管理的副本。
************************************
麻烦 #1：因为你移动/拷贝这些副本，副本列表就会增加超时，你就会看到越来越多的副本出现（例如）在Access 工具|复制|同步dropdrown 和复制管理器的副本列表中。如果你在两台机器之间来回拷贝，那么，所有假副本将是相同的路径……所以，在列表中，你可能会以数千的"c:\foo\bar.mdb"副本而结束。移动这些项目并不是件小事（实质上，Jet只有被移动时才标志，而且传播该信息给其他副本，如果你同步给它，它就会找到路径而不是文件……所以，如意它找到c:\foo\但没有bar.mdb的话，它就会删掉它。如果你这样做1000次，你就得删掉上千的输入。也有其他不理想的方法“删掉”假副本，但这些方法都不比这个方法有效。
************************************
设计问题 #1：Microsoft Jet 3.5x有个限制64,000的同步装置为副本“所知”。显然，对于大多数应用程序来说，这不是问题，但意味着，如果你不用同步装置管理副本，Jet就会创建一个“虚拟”的同步装置，你可以用来与真正的同步装置同步（对于因特网同步等来说非常好！）这就是说，当你持续拷贝，你最终将有64,000个非法副本，这样，你又得工作了，你已经弄糟了你的副本设置，不进行大量的工作你是不可能修复它的。
************************************
设计问题 #2：数据冲突，当两人更新相同行时，并只在Jet 3.5丢失副本中被报告，那么，数据冲突就会发生。如果你有副本,该副本丢失了冲突但已移动了副本（在你输入数据的时间和你同步将被报告冲突的时间之间），则要记住，它现在是一个新副本，这样，你就丢失了被包含在冲突表中的数据。这个数据丢失显然是很严重的。
************************************
设计问题 #3：当两人影响到db完整性时，就会发生糟糕的数据错误（最简单的方法是，当两人把相同的主键码放在新记录中然后同步）。任何时候你同步，Jet都会假设你修复了问题，而且会“再试” 同步来看问题是否解决了。如果发现问题仍存在，它就会停止同步（这样就不再需要工作，也没有其他记录被传送了）。 因为被报告的数据错误信息被约束在其来自的副本上等，当存在问题的副本丢失，要跟踪数据错误的原因是很难的……只有一些人知道谁能够处理这些情况，而不用进行极端非复制/再复制解决方案。注意，当有数据错误时，同步就没有完全完成……所以，不是所有的副本都获得所有的数据，这样，你就处于某种非一致状态。你就没有发生位置的运算次序控制。
************************************
代码：最后，整个方案（因为它不被支持）就不能得到其他方案得到的扩展加压测试。我们可以利用Microsoft的产品测试，但事实是，加压测试是至关重要的，而且他们不被测试就意味着，除了以上问题外（这个我一直在寻找，分辨和修复好几年了）可能还有其他问题没有发现。那些责备MS的人多数是因为他们产品中的错误，他们将不再抱怨。
对于记录，在Jet复制被载之前，对于Jet 3.0，以上的问题都不为所知或理解。然而，我始终劝人们，不应拷贝或移动存在数据的副本。原因是*我*留意到了以上的忠告，我不做不被支持的工作。因此，我创建的应用程序没有一个碰到过任何这些问题。但是，近几年，我个人则参与了帮助70个以上不同的应用程序的恢复工作，它们仅仅是由于这个结果而出现了严重的问题。估计用户总费用是很高的，因为人们顽固地坚持这样做，却忽视了这些警告。
************************************
所以，为什么不“象Mike” :-)，不去做那些不被支持和不被测试的工作，特别是他们已经被证明会导致扩展问题的在这个方面？
