我目前遇到一个问题,即在笔记本电脑上使用多个(相同架构)访问 2003 数据库。

我需要找到一种自动化方法将数据同步到中央访问数据库中。

笔记本电脑上的数据仅被附加,因此更新/删除操作不会成为问题。

哪些工具可以让我轻松地做到这一点?哪些因素会影响最佳工具或解决方案的决策?

有帮助吗?

解决方案

可以使用Access中内置的Jet复制,但我会警告你,它非常不稳定。它会在你执行它的任何表上搞乱你的PK因为它选择随机有符号整数来尝试避免键冲突,所以你可能最终得到-1243482392912作为给定记录的下一个PK。如果您正在对其进行任何类型的查找(例如客户ID,订单号等),那就是输入的PITA。您无法自动执行Access同步(也许您可以使用VBA伪造类似的东西。但仍然,只有在打开数据库时才会运行。)

我建议的方法是在您的“中心”上使用SQL Server 2005/2008。数据库并使用SQL Server Express Edition作为“远程”的后端。数据库,然后使用Access中的链接表连接到这些SSEE数据库和复制以同步它们。设置合并复制或快照复制与您的”中心“数据库作为发布者,您的SSEE数据库作为订阅者。与Access Jet复制不同,您可以控制PK编号,但对您而言,这不会成为问题,因为您的订阅者不会推动更改。

除了SQL服务器带来的可扩展性之外,您还可以使用Windows同步管理器自动执行此操作(如果您有同步文件夹,那就是弹出并在登录/注销时同步它们的烦人小盒子),并设置它up,以便在给定的时间间隔,启动,关闭或一天中的某个时间和/或计算机空闲时进行同步,或者仅按需同步。即使Access未运行一个月,每次用户连接到网络时都可以更新其数据集。很酷的东西。

其他提示

访问复制可能很尴尬,因为您只需要附加查询和一些检查,最好自己编写一些东西。如果每台笔记本电脑收集的数据不能重叠,这可能不会太困难。

您需要考虑主键。最好将用户或笔记本电脑名称合并到密钥中,以确保记录正确相关。

这个帖子中的答案充满了关于Jet Replication的错误信息,这些人显然没有使用它,只是重复他们听过的事情,或者将问题归咎于实际反映应用程序设计错误的Jet Replication。

  

可以使用Jet   复制内置到Access中,但我   会警告你,这是非常不稳定的。

Jet Replication并不好看。正确使用时非常可靠,就像任何其他复杂工具一样。确实,在非复制数据库中导致没有问题的某些事情在复制时可能会导致问题,但这是有道理的,因为任何数据库引擎所需的复制的性质。

  

它也会搞砸你的PK   无论你做什么表,因为   它选择随机签名整数来尝试   并避免关键的碰撞,所以你可能   最终得到-1243482392912作为你的   在给定记录上的下一个PK。那是一个   PITA如果您正在做任何事情,请输入   对它的一种查找(就像一个客户   ID,订单号等。)

代理自动编号PK首先不应该暴露给用户。它们是用于在幕后加入记录的无意义数字,如果您将它们暴露给用户,那么您的应用程序设计就会出现错误。

如果您确实需要序列号,则必须自行处理并处理如何防止副本之间发生冲突的问题。但这是任何数据库引擎中的复制问题。 SQL Server提供了在数据库引擎级别为各个副本分配序列号块的功能,这是一个非常好的功能,但它的代价是增加了维护多个SQL Server实例的管理开销(包含所有安全性和性能问题)这需要)。在Jet Replication中,您必须在代码中执行此操作,但这不是一个复杂的问题。

另一种选择是使用复合PK,其中一列表示源复制品。

但这不是Jet的Replication实现中的一些缺陷 - 对于任何需要有意义的序列号的复制场景来说都是一个问题。

  

您无法自动化Access   同步(也许你可以假装   使用VBA之类的东西。但   仍然,那只会在   数据库已打开。)

这显然是不真实的。如果安装Jet同步器,则可以安排同步(直接,间接或Internet同步)。即使没有它,您也可以安排VBScript定期运行并进行同步。这些只是实现自动Jet同步的两种方法,无需打开Access应用程序。

MS文档的引用:

  

使用Jet和复制对象

JRO实际上不是管理Jet Replication的最佳方式。首先,它只有DAO本身缺少的一个功能,即能够在代码中启动间接同步。但是如果你要为你的应用程序添加一个依赖项(JRO需要一个引用,或者可以通过后期绑定使用),你也可以添加一个真正有用的库来控制Jet Replication,这就是 TSI Synchronizer ,由Michael Kaplan创建,他曾是世界上最重要的专家Jet Replication(后来他转向国际化作为他的专注领域)。它为您提供Jet暴露的几乎所有复制功能的完全编程控制,包括调度同步,启动各种同步以及急需的MoveReplica命令(在不破坏复制的情况下移动或重命名副本的唯一合法方法)。

你应该阅读 使用权 数据库 复制, ,因为那里有一些信息。

但我认为,为了使其能够与您的应用程序一起正常工作,您必须使用以下方法推出定制的解决方案 可用的方法和属性 为了这个目的。

如果需要以编程方式控制 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 方法

你绝对应该阅读 同步数据 文档的一部分。

我在a00中使用复制多年,直到被迫升级到a07(当它消失时)。我们在企业级遇到的最棘手的问题是管理 CONFLICTS 。如果不及时管理,或者太多,用户会感到沮丧,数据变得不可靠。

当我们的远程站点并不总是连接到互联网时,

复制确实运行良好。这使他们能够处理他们的数据,并在他们可以的时候进行同步。每天至少两次。

我们在管理同步的远程计算机上安装了一个单独的数据库,因此用户只需单击其桌面上的图标即可唤起同步。

用户有一个单独的按钮,可以从指定的FTP文件中推送/拉入Feed,该文件将从旧版系统更新。

这个过程非常有效,因为我们有30个这样的“节点”。在全国各地工作,管理他们的数据并更新到FTP服务器。

如果您正在认真考虑这条道路,请告诉我,我可以将您的文件发给您。

您可以编写自己的同步软件,连接到笔记本电脑,从它的数据库中选择差异并将其插入主服务器。 这取决于您的数据方案,此操作将是多么容易。 (如果你有许多FK表...你需要巧妙地做到这一点)。 我认为如果你自己写的话会最有效率。

自动执行此类行为称为复制,并访问支持显然,但我从未见过它实施过。

我猜大多数时候笔记本电脑没有连接到主数据库,无论如何都不是一个好主意(复制数据)。

如果您要寻找第三方工具来做 - 在复制之前寻找可以轻松地在表之间进行差异的东西,并且当然可以逐步进行。

前言:

  1. 自动编号。我同意大卫的观点——他们不应该被曝光。为了消除这种诱惑,我使用了随机自动编号。
  2. 复制。几年前我广泛使用了这个,通过预定的同步,并使用 GUID 作为 PK。我反复发现网络上的任何故障都会损坏副本,结果我不得不挽救数据并重新发布副本。痛苦!
许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top