同步 MS Access 数据库文件
我正在开发一个数据库，其中约有 10 个表。基本上它将用于 2 或 3 个遥远的地理位置（我们称它们为 A、B 和 C）。所需的工作流程如下： A、B 和 C 应该始终具有相同的数据库。因此，当 A 进行任何更改时，他应该能够将这些更改发送给 B 和 C。通过电子邮件发送整个 mdb 文件没有意义，因为它的大小为 15+mb。因此，我只想将新的附加记录和更改发送给 B 和 C。B 和 C 所做的更改也应该反映给其他相关方。我该怎么做？ 我心里有一些想法，但不知道如何实施。
解决方案“A”-仅将数据表导出到 xls 文件中并通过电子邮件发送。但是将表导入 mdb 文件可能有点复杂，对吧？并且xls文件也会随着时间变得越来越大。
解决方案“B”-尝试仅提取更改并仅通过电子邮件发送新部分？ （但如何提取这些）
解决方案“C” - 找到某种方法将所有用户同步到同一数据库（存储）位置。我正在考虑通过将表存储在母公司服务器（也在海外）的共享驱动器中来实现前后端分离解决方案。但地点之间的网络连接非常慢，我不知道这需要多少带宽。
任何建议将非常受欢迎！
I am developing a database with about 10 tables in it. Basically it will be used in 2 or 3 distant geographical locations (let's call them A,B and C). The desired work flow will be as follows:
A,B and C should always have the same database. So when A does any changes he should be able to send those changes over to B and C. Emailing the entire mdb file doesnt make sense since its 15+mb in size. So I would like to send the new additional records and changes only to B and C. The changes B and C make should also be reflected to the other repective parties. How can I do this?
I have a few ideas in mind but cont know how to implement it.
solution 'A' - export the data tables only into a xls file and email that. But the importing of the tables into the mdb file could be a bit complex right? and the xls is file will also become bigger and bigger with time.
solution 'B' - try extract just the changes and email only the new parts? (but how to extract just those)
Solution 'C' - find some way of syncing all users onto the same database(storage) location. I was thinking of a front/back end splitting solution by storing the tables in a shared drive in the parent company's server (which is also overseas). But the network connection between locations is very slow, and I dont know how much bandwidth is needed for this.
Any recomendations would be most welcome!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
关于复制信息的来源，请从我的 Jet Replication Wiki 开始。
但我绝不会在您的场景中推荐 Jet 复制。我目前推荐它的唯一环境（自 1997 年以来我一直在制作复制的应用程序，并且仍然有几个在生产中使用）是用于支持笔记本电脑用户，这些用户必须在与任何网络断开连接的现场处理实时数据，并返回到家庭办公室并直接与母船同步。
使用 Access 应用程序的最简单的解决方案是将应用程序托管在 Windows 终端服务器/Citrix 上，用户将通过远程桌面连接或使用 Sharepoint 运行它。终端服务器/Citrix 解决方案无法适应断开连接的用户，但 Sharepoint 可以适应离线使用并在连接时同步更改。 Access 2010 和 Sharepoint 2010 提供了许多新功能，包括更好的架构设计、相当于触发器以及大大改进的大型 Sharepoint 列表的性能，因此对我来说，如果您选择 Sharepoint，您会想要使用 A2010和 Sharepoint 2010。
虽然可以使用 Jet Replication 完成您想要的操作，但它需要在服务器和客户端上进行大量设置，并且相对脆弱（如果您使用间接复制，则不考虑数据完整性（因为您应该），但就网络可靠性而言）——移动部件太多，故障点太多。
Windows Terminal Server/Citrix 是迄今为止最简单的，具有最少的移动部件和完全集中的管理，并且在相对较小的投资下运行良好。
Sharepoint 比 WTS/Citrix 更复杂，但比 Jet Replication 解决方案复杂度更低且更集中。
如果是我，如果不需要断开连接使用，我可能会选择 WTS/Citrix，但我会垂涎欲滴地尝试 A2010/Sharepoint 2010。如果需要断开连接使用，那么我会肯定走Sharepoint路线。
In regard to sources for information on replication, start with my Jet Replication Wiki.
But I would never recommend Jet replication for your scenario. The only environment where I currently recommend it (and I've been doing replicated apps since 1997 and still have several in production use) is for supporting laptop users who have to work with live data in the field disconnected from any network, and return to the home office and synch direct with the mother ship.
The easiest solutions with an Access application would be hosting the app on Windows Terminal Server/Citrix and the users would run it over a Remote Desktop Connection, or using Sharepoint. The Terminal Server/Citrix solution has no accomodation for disconnected users, but Sharepoint can accomodate offline usage and synch changes when connected. Access 2010 and Sharepoint 2010 provide a host of new features, including better schema design, the equivalent of triggers and greatly improved peformance for large Sharepoint lists, so it's a no-brainer to me that if you choose Sharepoint you'd want to use A2010 and Sharepoint 2010.
While it's possible to do what you want with Jet Replication, it requires a lot of setup on the server and client ends, and is relatively fragile (not in terms of data integrity if you're using indirect replication (as you should), but in terms of network reliability) -- there are too many moving parts and too many failure points.
Windows Terminal Server/Citrix is by far the simplest, with the fewest moving parts and completely centralized administration, and works very well for a relatively small investment.
Sharepoint is more complicated than WTS/Citrix, but is less complex and more centralized than a Jet Replication solution.
If it were me, I'd probably go with WTS/Citrix if there was no need for disconnected usage, but I'd be salivating over trying out A2010/Sharepoint 2010. If there was a need for disconnected usage, then I'd definitely go the Sharepoint route.
您想使用“Jet Replication”。请参阅
MSDN 搜索 jro，网址为 http://social.msdn.microsoft.com/Search/en-US?query=jro&ac=8
MSDN 在http://social.msdn.microsoft.com/Search/en-US?query=access%20replication&ac=3< /a>
You want to use "Jet Replication". See
MSDN Search for jro at http://social.msdn.microsoft.com/Search/en-US?query=jro&ac=8
MSDN Search for access replication at http://social.msdn.microsoft.com/Search/en-US?query=access%20replication&ac=3
我已经有一段时间没有这么做了，但在类似的情况下，间接复制方法对我来说效果很好。
这需要一些东西来设置。文档曾经对此感到震惊，但我发现 Michael Kaplan（又名 Michka）撰写的文章引导我了解了如何做到这一点。
如果您的最终环境相当稳定，则全程使用 Access。如果没有，那么我强烈建议您采纳 HansUp 的建议并使用 SQL Server 或 SharePoint。
请注意：如果您使用的是 Access 2007 或更高版本，则不直接支持复制，您必须自行进行一些工作。如果您使用的是较早的安装，那就没问题，但请留出一些时间来解决一些问题。
It's been some time since I did it, but the indirect method of replication worked well for me in a similar situation.
It takes something to set up. The documentation used to be appalling for it, but I found articles written by Michael Kaplan (aka Michka) that walked me through how to do it.
If your final environment is going to be fairly stable, then use Access the whole way. If not, then I'd urge you to take HansUp's advice and go with SQL Server or SharePoint.
Do note: if you're working in Access 2007 or later, replication is not directly supported, and you'll have to roll-your-own bits and pieces. If you're using an earlier installation, you'll be fine, but allow time for some head-scratching.