我目前遇到的问题是，在笔记本电脑上使用多个（相同模式）Access 2003数据库。
我需要找到一种自动同步数据到中央访问数据库的方法。
笔记本电脑上的数据仅追加，因此更新/删除操作不会成为问题。
哪些工具可以让我轻松完成这个任务？ 决定最佳工具或解决方案的因素有哪些？
7个回答
6
访问复制可能会很麻烦，如果您只需要带有一些检查的附加查询，则最好自己编写。 如果每台笔记本电脑收集的数据不能重叠，则这可能不太困难。
您需要考虑主键。 最好将用户或笔记本电脑名称纳入键中以确保记录正确关联。
- Fionnuala
6
可以使用Access内置的Jet复制功能，但我要警告你，它相当不稳定。它还会在你所使用的任何表上搞乱主键，因为它选择随机有符号整数来避免键冲突，所以你可能会得到-1243482392912作为给定记录上的下一个主键。如果你需要对其进行任何查找（如客户ID、订单号等），那么输入这个值将是一件很麻烦的事情。你不能自动同步Access（也许你可以通过使用VBA来伪造类似的东西，但仍然只能在打开数据库时运行）。
我建议的方法是，在“中央”数据库上使用SQL Server 2005/2008，并在“远程”数据库上使用SQL Server Express Editions作为后端，然后使用Access中的链接表连接到这些SSEE数据库并使用复制来进行同步。 使用你的“中央”数据库作为发布者，SSEE数据库作为订阅者，设置合并复制或快照复制。与Access Jet复制不同，你可以控制PK编号，但对你来说，这不是问题，因为你的订阅者不会推送更改。
除了 SQL Server 带来的可扩展性之外，您还可以使用 Windows 同步管理器自动化此过程（如果您有同步文件夹，则会弹出一个烦人的小框，在您登录/注销时同步它们），并设置它以在给定间隔、启动、关闭、某个时间或计算机空闲时进行同步，并且/或仅在需要时进行同步。即使 Access 一个月没有运行，其数据集也可以在用户连接到网络时每次更新。非常酷的东西。
除了 SQL Server 带来的可扩展性之外，您还可以使用 Windows 同步管理器自动化此过程（如果您有同步文件夹，则会弹出一个烦人的小框，在您登录/注销时同步它们），并设置它以在给定间隔、启动、关闭、某个时间或计算机空闲时进行同步，并且/或仅在需要时进行同步。即使 Access 一个月没有运行，其数据集也可以在用户连接到网络时每次更新。非常酷的东西。
- Dale
4
如果我能给这个答案-10分，那么它完全背叛了Jet Replication的知识。首先，Jet Replication并不会出现问题。其次，担心Autonumber值表明您正在误用Autonumbers——它们是没有意义的，无论它们是负数还是极大或极小的数字都不应该有影响。同步当然可以自动化。请参见下面我的详细答案。 - David-W-Fenton
针对你的观点，David，我知道你是Access的忠实粉丝；在适当的情况下，我也是，但这并不是其中之一。我没有说Jet复制不能自动化，只是自动化Jet需要额外的VBA代码，并且只有在数据库打开并且代码能够运行时才能工作。人们通常将自动编号字段用作PK，例如订单/报价/客户ID，而Jet复制会对这些字段进行一些奇怪的处理，因为它无法像SQL那样管理PK分区。 - Dale
不赞成在逻辑模型中使用IDENTITY值。David W. Fenton是正确的，代理键值不应该暴露给用户（任何用户，包括Access高级用户、开发人员、SQL编码人员等）。 - onedaywhen
4我不同意。用户应该期望身份字段的行为保持一致，并能够使用这些字段引用数据。Jet销毁PK/IDENTITY的增量以避免冲突，并不意味着其他人做得不正确。Jet复制可以被使用或滥用，不幸的是很多人试图强迫其按照自己的意愿改变，而不是意识到其局限性。 - Dale
4
这个帖子中的答案充斥着关于Jet复制的错误信息，这些信息来自那些显然没有使用过它并且只是重复他们听到的东西的人，或者将问题归咎于Jet Replication实际上反映了应用程序设计错误的人。
Jet Replication不是靠不住的。当正确使用时，它像任何其他复杂工具一样是完全可靠的。的确，在非复制数据库中不会引起问题的某些事情在复制时可能会导致问题，但这是因为任何数据库引擎所涉及的复制的本质。
它还会在你使用它的表上搞乱你的PK，因为它选择随机有符号整数来尝试避免键冲突，所以你可能会得到-1243482392912作为给定记录的下一个PK。如果你需要在它上面做任何查找（如客户ID、订单号等），那么输入这个数字就很麻烦。
自动编号的代理PK首先不应该暴露给用户。它们是用于在幕后连接记录的无意义数字，如果你向用户公开它们，那么这是你的应用程序设计错误。
如果你确实需要序列号，你将不得不自己编写代码，并处理如何防止副本之间的冲突的问题。但这是任何数据库引擎中复制的问题。SQL Server提供了为单个副本分配块序列号的功能，这是一个非常好的功能，但它需要维护多个SQL Server实例（包括所有安全性和性能问题）的增加管理开销。在Jet Replication中，你必须在代码中完成这个过程，但这并不是一个复杂的问题。
另一种选择是使用复合PK，其中一列表示源副本。
但这不是Jet复制实现中的某些缺陷——这是任何需要有意义的序列号的复制场景的问题。
你不能自动同步Access（也许你可以通过使用VBA来伪造类似的东西。但仍然只有在打开数据库时才会运行）。
这是明显不正确的。如果安装Jet同步器，您可以安排同步（直接、间接或Internet同步）。即使没有它，你也可以定期运行VBScript来进行同步。这些只是在不需要打开Access应用程序的情况下实现自动Jet同步的两种方法。
MS文档的一句话：使用Jet和Replication对象。
JRO并不是管理Jet Replication的最佳方法。首先，它只有一个DAO本身缺少的功能，即在代码中启动间接同步的能力。但是，如果你要添加对应用程序的依赖项（JRO需要引用或可以通过后期绑定使用），那么你可能会想要添加一个真正有用的库来控制Jet Replication，那就是由Michael Kaplan创建的TSI Synchronizer，他曾经是Jet Replication的世界顶级专家（现已转向国际化作为他的专业领域）。它为你提供了几乎所有Jet公开的复制功能的完全编程控制，包括调度同步、启动各种同步以及非常需要的MoveReplica命令（唯一合法的移动或重命名副本的方式，而不会破坏复制）。
JRO是Microsoft放弃ADO-Everywhere运动的丑陋的孩子之一。它的目的是提供Jet特定的功能来补充ADO本身支持的功能。如果你没有使用ADO（在具有Jet后端的Access应用程序中不应该使用），那么你真的不想使用JRO。正如我上面所说，它只增加了一个在DAO中不可用的函数（即启动间接同步）。我不禁想，Microsoft创建了一个独立的库来处理Jet特定的功能，然后故意省略了所有他们本可以支持的非常有用的函数。
既然我已经解决了上面提供的错误主张，那么这是我的建议：
因为你有一个仅追加的基础架构，请像@Remou建议的那样设置一些东西，手动发送新记录到需要的任何地方。而且他说得对，你仍然必须处理PK问题，就像使用Jet Replication一样。这是因为这是在多个位置添加新记录所必需的，并且适用于所有复制/同步应用程序。
但是要注意：如果将来的仅添加场景发生变化，你将会遇到麻烦，必须从头开始或编写大量复杂的代码来管理删除和更新（这并不容易-相信我，我已经做过！）。只使用Jet Replication的一个优点（即使它最有价值的是双向同步，即在多个位置进行编辑）是它将在没有任何问题的情况下处理仅添加场景，然后轻松处理完整合并复制，如果将来需要。
最后，Jet Replication的一个好起点是Jet Replication Wiki。资源、最佳实践和不可信的事项页面可能是开始的最佳位置。
Jet Replication不是靠不住的。当正确使用时，它像任何其他复杂工具一样是完全可靠的。的确，在非复制数据库中不会引起问题的某些事情在复制时可能会导致问题，但这是因为任何数据库引擎所涉及的复制的本质。
它还会在你使用它的表上搞乱你的PK，因为它选择随机有符号整数来尝试避免键冲突，所以你可能会得到-1243482392912作为给定记录的下一个PK。如果你需要在它上面做任何查找（如客户ID、订单号等），那么输入这个数字就很麻烦。
自动编号的代理PK首先不应该暴露给用户。它们是用于在幕后连接记录的无意义数字，如果你向用户公开它们，那么这是你的应用程序设计错误。
如果你确实需要序列号，你将不得不自己编写代码，并处理如何防止副本之间的冲突的问题。但这是任何数据库引擎中复制的问题。SQL Server提供了为单个副本分配块序列号的功能，这是一个非常好的功能，但它需要维护多个SQL Server实例（包括所有安全性和性能问题）的增加管理开销。在Jet Replication中，你必须在代码中完成这个过程，但这并不是一个复杂的问题。
另一种选择是使用复合PK，其中一列表示源副本。
但这不是Jet复制实现中的某些缺陷——这是任何需要有意义的序列号的复制场景的问题。
你不能自动同步Access（也许你可以通过使用VBA来伪造类似的东西。但仍然只有在打开数据库时才会运行）。
这是明显不正确的。如果安装Jet同步器，您可以安排同步（直接、间接或Internet同步）。即使没有它，你也可以定期运行VBScript来进行同步。这些只是在不需要打开Access应用程序的情况下实现自动Jet同步的两种方法。
MS文档的一句话：使用Jet和Replication对象。
JRO并不是管理Jet Replication的最佳方法。首先，它只有一个DAO本身缺少的功能，即在代码中启动间接同步的能力。但是，如果你要添加对应用程序的依赖项（JRO需要引用或可以通过后期绑定使用），那么你可能会想要添加一个真正有用的库来控制Jet Replication，那就是由Michael Kaplan创建的TSI Synchronizer，他曾经是Jet Replication的世界顶级专家（现已转向国际化作为他的专业领域）。它为你提供了几乎所有Jet公开的复制功能的完全编程控制，包括调度同步、启动各种同步以及非常需要的MoveReplica命令（唯一合法的移动或重命名副本的方式，而不会破坏复制）。
JRO是Microsoft放弃ADO-Everywhere运动的丑陋的孩子之一。它的目的是提供Jet特定的功能来补充ADO本身支持的功能。如果你没有使用ADO（在具有Jet后端的Access应用程序中不应该使用），那么你真的不想使用JRO。正如我上面所说，它只增加了一个在DAO中不可用的函数（即启动间接同步）。我不禁想，Microsoft创建了一个独立的库来处理Jet特定的功能，然后故意省略了所有他们本可以支持的非常有用的函数。
既然我已经解决了上面提供的错误主张，那么这是我的建议：
因为你有一个仅追加的基础架构，请像@Remou建议的那样设置一些东西，手动发送新记录到需要的任何地方。而且他说得对，你仍然必须处理PK问题，就像使用Jet Replication一样。这是因为这是在多个位置添加新记录所必需的，并且适用于所有复制/同步应用程序。
但是要注意：如果将来的仅添加场景发生变化，你将会遇到麻烦，必须从头开始或编写大量复杂的代码来管理删除和更新（这并不容易-相信我，我已经做过！）。只使用Jet Replication的一个优点（即使它最有价值的是双向同步，即在多个位置进行编辑）是它将在没有任何问题的情况下处理仅添加场景，然后轻松处理完整合并复制，如果将来需要。
最后，Jet Replication的一个好起点是Jet Replication Wiki。资源、最佳实践和不可信的事项页面可能是开始的最佳位置。
- David-W-Fenton
1
你应该深入了解访问 数据库 复制，因为有一些相关信息可以参考。
但我认为，为了使其与你的应用程序正确配合，你需要使用可用的方法和属性来推出一个定制化的解决方案。
如果您需要在 Microsoft Access 数据库 (.mdb 文件) 的副本集成员之间交换数据和设计信息时进行编程控制，可以使用 Jet 和复制对象 (JRO)。例如，您可以使用 JRO 编写一个过程，在用户打开数据库时自动将用户的副本与剩余的集合同步。要以编程方式复制数据库，必须关闭数据库。如果您的数据库是使用 Microsoft Access 97 或更早版本创建的，则必须使用数据访问对象 (DAO) 进行编程复制和同步。
您可以使用 DAO 方法和属性在 Microsoft Access 的早期版本中创建和维护复制数据库。如果您需要在副本集成员之间进行数据和设计信息的编程控制，可以使用 DAO。例如，您可以使用 DAO 编写一个过程，在用户打开数据库时自动将用户的副本与剩余的集合同步。
您可以使用以下方法和属性来创建和维护复制数据库：
- MakeReplica 方法 - Synchronize 方法 - ConflictTable 属性 - DesignMasterID 属性 - KeepLocal 属性 - Replicable 属性 - ReplicaID 属性 - ReplicationConflictFunction 属性
Microsoft Jet 还提供了这些额外的方法和属性，用于创建和维护部分副本 (包含完整副本中记录子集的副本)：
- ReplicaFilter 属性 - PartialReplica 属性 - PopulatePartial 方法
你绝对应该阅读文档中的数据同步部分。
- Esteban Küber
2
JRO是无用的，因为它除了在代码中启动间接同步之外，不支持DAO不能做的任何事情。TSI Synchronizer提供了更多的控制，尽管它是一个不受支持的非微软产品。但它是由世界上最杰出的Jet复制专家创建的，实际上现在是微软的员工。 - David-W-Fenton
@David W. Fenton：听起来你是在说JRO做了DAO所有关于同步的事情，再加上一个功能。这对我来说并不无用！我经常使用JRO来压缩MDB和ACCDB文件，所以我是活生生的证明它不是无用的 ;) - onedaywhen
0
我曾经在a00中使用复制功能多年，直到被迫升级到a07（当时它消失了）。在企业级别上，我们遇到的最棘手的问题是管理冲突。如果不能及时处理或者冲突太多，用户会感到沮丧，数据也会变得不可靠。
当我们的远程站点没有始终连接到互联网时，复制确实运行良好。这使他们能够使用自己的数据，并在可以的时候进行同步。至少每天两次。
我们在远程计算机上安装了一个单独的数据库来管理同步，因此用户只需单击桌面上的图标即可调用同步。
用户有一个单独的按钮来推送/拉取指定FTP文件中的源，该文件将从传统系统更新。
这个过程非常有效，因为我们有30个这样的“节点”在全国范围内工作，管理他们的数据并更新到FTP服务器。
如果您认真考虑这条路，请告诉我，我可以给您发送我的文档。
- ljvincent
-2
你可以编写自己的同步软件，连接到笔记本电脑并选择其数据库中的差异，将其插入到主数据库中。
这取决于您的数据方案，操作的复杂程度也会不同。（如果有很多带有外键的表格...则需要进行巧妙的操作）。
我认为如果您自己编写它，那么效率最高。
自动化这种行为称为复制，Accesss 支持 这一点，但我从未见过实施。
由于大部分时间笔记本电脑没有连接到主数据库，因此无论如何都不是一个好主意（去复制数据）。
如果您要寻找第三方工具来执行此操作，请查找可以轻松执行表之间差异的工具，并且当然可以逐步执行。
自动化这种行为称为复制，Accesss 支持 这一点，但我从未见过实施。
由于大部分时间笔记本电脑没有连接到主数据库，因此无论如何都不是一个好主意（去复制数据）。
如果您要寻找第三方工具来执行此操作，请查找可以轻松执行表之间差异的工具，并且当然可以逐步执行。
- Dani
-2
顺便说一下：
- 自动编号。我同意David的观点 - 它们永远不应该被公开。为了消除这种诱惑，我使用随机自动编号。
- 复制。几年前，我广泛使用了这个功能，进行定期同步，并使用GUID作为PK。我反复发现，网络上的任何小问题都会破坏副本，导致我不得不挽救数据并重新发布副本。令人痛苦！
- maxhugen
1
如果您在除有线局域网（10Mbps+）以外的任何地方执行直接同步，则使用的方法是错误的。对于广域网、WiFi或Internet同步，您需要使用Internet或间接同步，这是完全安全的，永远不会破坏副本。它也更加高效，因为它仅发送增量，而不是通过电线拉取整个远程副本。换句话说，您遇到的问题是由飞行员错误引起的，而不是Jet Replication的缺陷。 - David-W-Fenton
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接