我使用Delphi XE4 Architect（Delphi Xe3也可以） 我需要找到解决以下问题的智能解决方案 我想使用其中一个框架：kbmMW或RemOjects SDK / DataAbstract或RealThinClient
目前，我有一个应用程序在站点A上使用非常简单的MSSQL数据库，站点B的用户通过远程桌面使用该数据库。 应用程序有时需要显示一些图片并查看一些PDF，但它主要是文本数据输入。
我没有特别的理由使用MSSQL， 但它是一个我发现已经活跃并填充的数据库，我自己没有建立它。 现在，改变它会很复杂。 （数据库并不重要，不使用特定功能，也不使用存储过程或触发器）
站点B的用户通过网络连接非常慢地连接到A站点 偶尔连接几小时到一天都不可用（这是主要问题）。 不幸的是，由于各种原因，这种联系的情况无法改善。
数据库非常简单，有很多表几乎没有变化， 大约十个而不是每天更新，可能会受到相互竞争的变化。
主要是这些表的记录包含在更新中锁定的数据 从一个用户编辑一些字段，然后他保存释放锁。
我希望得到一些非常不同的优化性能。
A站点的用户具有更高的优先级，它们更重要，因为A站点是总部。
我想在站点A到站点B有一份数据库副本， 这样，无需使用连接到站点A的远程桌面，站点B的用户就可以在本地工作，速度更快。 RDP协议没有得到很好的优化，在任何情况下如果没有连接，用户就无法工作。
同步和更新两个数据库之间的数据库锁记录可能不是一个大问题。
基本上，当站点B的用户获取编辑数据库B中的记录时， 显然，站点A的用户不应该能够修改站点A的数据库上的相同记录。 当然，这也应该在相反的方向上起作用。
我的一个大问题是弄清楚如何处理最好的情况 当B和A之间的连接在几个小时内不可用时。 （交易/事件在站点B上增加）。 站点A上的事件通常优先于（碰撞时）站点B上的事件。
站点B的用户必须能够继续工作。 当连接变为活动状态时，应将更改发送到站点A的数据库。 显然这可能会导致冲突，但记录会发生变化 可能被用户B丢弃或者可以在选择性合并的监督下完成 和网站B的记录用户的批准记录。
嗯，我希望这个场景几乎可以清楚解释。
其他信息：
数据库架构非常简单，只有表，没有触发器，存储过程。所以我可以构建一个作为示例，但想象一下可以并发更新的10个表。
DB由销售部门的桌面应用程序使用，因此它包含大多数机密数据。
远程连接通常最大512Kbit，但这里的主要问题是连接有时可能无效 并且远程站点上的用户无论如何都必须工作。这是主要焦点。
每日更新的总数据最多可达10 Mb，压缩，仅适用于数据库连接。还有一些其他数据同步 在同一个连接上，但他们不是这项工作的一部分。
我不想使用特定的MSSQL工具或服务（复制等），因为DB将来可能会发生变化。
由于
答案 0 :(得分：0)
我们使用Delphi客户端应用程序，一个基于kbmMW的Delphi服务器应用程序，MSSQL数据库（尽管它过去在DBISAM数据库上工作得很开心）也几乎完成了这一点。
我们有一些表只允许总公司网站用户修改。每次存在“合并”时，较小的表格将完整地传输。较大的表和事务类型表都具有添加日期和/或日期修改字段，并且仅传输在过去3周左右（可配置）中已更改或添加的那些记录。这意味着站点仍然可以更新到最新数据，即使它们已经断开了相当长的一段时间 - 我们曾经在偏远的地方让客户端使用可疑的拨号线路！
我们每天只运行一次或两次合并例程，但它可以按小时或其他时间表同样运行。
在每天的特定时间，每个站点（包括总部）将其更改的/新记录“导出”到文件（例如客户端数据集表或类似表）。然后将这些应用程序压缩并放在“传出”文件夹中。 zip文件根据位置ID，日期，时间等命名。文件通过一些外部手段传输，例如通过FTP /文件共享/电子邮件等等。每个分支机构将其数据文件发送/传输到总公司和总部。将其数据传输到每个分支。文件通过任何方式传输到“传入”文件夹。
定期（例如每小时），每个位置都会对传入的文件夹进行检查，以查看是否有新内容要导入。如果是这样，它会添加所有新记录，分支位置会用新的记录覆盖总部数据表，编辑的记录将以“某种方式”合并。这是棘手的一点。最简单的政策是“总公司获胜”，因此所有编辑都被接受，除非存在冲突，在这种情况下总公司版本获胜。或者，您可以使用“最后编辑的胜利” - 但是您需要确保时钟在不同位置同步。另一种选择是将冲突记录添加到某种形式的“悬念”状态，并让最终用户在将来的某个时候做出决定。我们在一个数据集上执行此操作。无论您选择哪种冲突方法，都需要以某种形式的日志表记录每个决策，并提示管理级用户偶尔进行检查。
当总公司导入数据或在总公司添加数据时，会设置一个字段以指示数据是主数据的一部分。当分支添加数据时，此字段为空以指示它尚未到达主集。这有助于分支导出数据，因为它们可以包含没有设置此字段的所有数据。
我们发现您无法以交互方式运行合并，因为您最终将无法完成任何工作，并且您将无法在晚上运行合并等。它需要具备完全自动化的能力管理员用户在事后的某个时刻进行调整。
我们多年来一直在使用这种方法进行多站点操作，一旦它安定下来，它的工作非常完美。我们每天有2个出口/进口计划，我们发现分支机构运行良好，并且只缺少不到一天的交易。在我们不经常发生冲突的场景中运行良好。导出的数据大约在5-10MB之间，足够小。
主键至关重要！我们使用GUID，它还没有让我们失望。
实际上，数据库服务器和n层框架的选择无关紧要。这是重要的过程。
基本上，当站点B的用户获取编辑数据库B中的记录时，显然站点A的用户不能修改站点A的数据库上的相同记录。这也应该在当然是相反的方向。
如果两个站点都拥有自己的数据库副本，并且有时允许删除/不存在的站点间连接，我无法看到你是如何使这个位工作可靠的。