合并具有冲突的唯一键值的数据库 [英] Merging databases with conflicting unique key values
问题描述
第3次发布此消息时，前两个消失了！
这就是问题所在：
我们目前在西方运行Access应用程序海岸跟踪
资源中心数据。对于那些位于西部的人来说，这个程序可以很好地拉扯
，但是东海岸的人们有一个噩梦般的
性能问题。
我们已经让我们的技术人员看了一眼，这是因为网络速度很长，并且没有什么可以做的。
我们已经减少了跳数，我们实际上在网络上
骨干。
计划的是什么do是在East
Coast的另一台服务器上创建一个副本。这样做对我们来说是一个严重的问题。所有表格都启用了自动ID，因此如果在两台机器上创建记录，试图将
合并，那么由于自动<而导致ID冲突，因此无法实现br />
ID将按顺序选择下一个数值。
我们无法创建复制版本，因为我们将拥有相同的网络
性能问题。有没有人为这个问题找到解决方案或解决方法？
3rd time posting this as the first two simply disappeared!
Here''s the issue:
We currently run an Access application in the West Coast for tracking
resource centric data. For those located in the West the program zips
along fine but the folks in the East Coast are having a nightmarish
performance issue.
We''ve had our tech guys take a look and it''s due to the network speed
across a long distance and there''s nothing much that can be done.
We''ve minimized the number of hops and we''re practically on the network
backbone.
What were planning to do is create a copy on another server on the East
Coast. Doing this poses a serious problem for us. All the tables have
auto ID enabled so if records are created on both machines trying to
merge them just won''t be possible due to conflicting IDs since the auto
ID will sequentially select the next numeric value.
We can''t create a replicated version as we''ll have the same network
performance issue. Has anyone found a solution or a workaround for
this problem?
推荐答案
lo ******* @ lycos.com 写道：
lo*******@lycos.com wrote:
>第3次发布此消息时，前两个消失了！
这就是问题：
我们目前在西海岸运行Access应用程序以跟踪资源中心数据。对于那些位于西方的人来说，这个项目很好地拉链了，但是东海岸的人们正面临着一场噩梦般的表现问题。
我们已经让我们的技术人员服用了一看，这是由于网络速度很长，并没有什么可以做的。
我们已经减少了跳数，我们是几乎在网络上。
计划做的是在东海岸的另一台服务器上创建一个副本。这样做对我们来说是一个严重的问题。所有表都启用了自动ID，因此如果在两台计算机上创建记录，试图合并它们，由于ID会发生冲突，因为自动
ID会依次选择下一个数值。
我们无法创建复制版本，因为我们会遇到相同的网络性能问题。有没有人为这个问题找到解决方案或解决方法？
>3rd time posting this as the first two simply disappeared!
Here''s the issue:
We currently run an Access application in the West Coast for tracking
resource centric data. For those located in the West the program zips
along fine but the folks in the East Coast are having a nightmarish
performance issue.
We''ve had our tech guys take a look and it''s due to the network speed
across a long distance and there''s nothing much that can be done.
We''ve minimized the number of hops and we''re practically on the network
backbone.
What were planning to do is create a copy on another server on the East
Coast. Doing this poses a serious problem for us. All the tables have
auto ID enabled so if records are created on both machines trying to
merge them just won''t be possible due to conflicting IDs since the auto
ID will sequentially select the next numeric value.
We can''t create a replicated version as we''ll have the same network
performance issue. Has anyone found a solution or a workaround for
this problem?
在表格中添加一个字段，这样你就可以识别出East vs
West。
-
Marsh
Add a field to the table so you can identify the East vs
West.
--
Marsh
在西海岸设置终端服务器，然后东海岸可以
连接到终端服务器上的会话以访问应用程序
或将数据（后端mdb）移动到msde或sql-server
louish ... @ lycos.com写道：
set up a terminal server on the west coast, then the east coast can
connect to a session on the terminal server to access the application
or moved the data (backend mdb) to msde or sql-server
louish...@lycos.com wrote:
第三次发布此消息时，前两个消失了！
这里是问题：
我们目前在西海岸运行一个Access应用程序来跟踪
资源中心数据。对于那些位于西部的人来说，这个程序可以很好地拉扯
，但是东海岸的人们有一个噩梦般的
性能问题。
我们已经让我们的技术人员看了一眼，这是因为网络速度很长，并且没有什么可以做的。
我们已经减少了跳数，我们实际上在网络上
骨干。
计划的是什么do是在East
Coast的另一台服务器上创建一个副本。这样做对我们来说是一个严重的问题。所有表格都启用了自动ID，因此如果在两台机器上创建记录，试图将
合并，那么由于自动<而导致ID冲突，因此无法实现br />
ID将按顺序选择下一个数值。
我们无法创建复制版本，因为我们将拥有相同的网络
性能问题。有没有人找到解决方案或解决方法
这个问题？
3rd time posting this as the first two simply disappeared!
Here''s the issue:
We currently run an Access application in the West Coast for tracking
resource centric data. For those located in the West the program zips
along fine but the folks in the East Coast are having a nightmarish
performance issue.
We''ve had our tech guys take a look and it''s due to the network speed
across a long distance and there''s nothing much that can be done.
We''ve minimized the number of hops and we''re practically on the network
backbone.
What were planning to do is create a copy on another server on the East
Coast. Doing this poses a serious problem for us. All the tables have
auto ID enabled so if records are created on both machines trying to
merge them just won''t be possible due to conflicting IDs since the auto
ID will sequentially select the next numeric value.
We can''t create a replicated version as we''ll have the same network
performance issue. Has anyone found a solution or a workaround for
this problem?
好主意，我们一直在鼓励这个想法，但我们在东海岸有多个
用户，所以前端将被多个用户同时访问
。它太不稳定了。
我们还考虑过使用SQL服务器作为后端，但是从我们的新闻组中读取的b $ b来看，性能下降了。
至于添加东/西列，我们需要重新编写（修复）所有
的查询和表单来进行这种组合密钥和区域a
唯一组合。
有没有办法将自动ID设置为一个mdb和奇数ID中的偶数
为另一个？还有其他可能的解决方谢谢。
lesperan ... @ natpro.com写道：
Great idea, and we were kicking this idea around but we have multiple
users on the east coast so the front end would be accessed concurrently
from multiple users. It''s just too unstable.
We also thought about using SQL server as the backend but from what we
read from the newsgroups performance goes way down.
As for adding a east/west column, we would need to re-write (fix) all
the queries and forms to make this combination of key and region a
unique combination.
Is there a way to set the auto ID to even IDs in one mdb and odd IDs
for the other? Any other possible solutions? Thanks.
lesperan...@natpro.com wrote:
在西海岸设立终端服务器，然后在东海岸可以
连接到终端服务器上的会话以访问应用程序
或将数据（后端mdb）移动到msde或sql-server
louish ... @ lycos.com写道：
set up a terminal server on the west coast, then the east coast can
connect to a session on the terminal server to access the application
or moved the data (backend mdb) to msde or sql-server
louish...@lycos.com wrote:
第3次发布此消息时，前两个消失了！
这就是问题：
我们目前在西海岸运行一个Access应用程序来跟踪
资源中心数据。对于那些位于西部的人来说，这个程序可以很好地拉扯
，但是东海岸的人们有一个噩梦般的
性能问题。
我们已经让我们的技术人员看了一眼，这是因为网络速度很长，并且没有什么可以做的。
我们已经减少了跳数，我们实际上在网络上
骨干。
计划的是什么do是在East
Coast的另一台服务器上创建一个副本。这样做对我们来说是一个严重的问题。所有表格都启用了自动ID，因此如果在两台机器上创建记录，试图将
合并，那么由于自动<而导致ID冲突，因此无法实现br />
ID将按顺序选择下一个数值。
我们无法创建复制版本，因为我们将拥有相同的网络
性能问题。有没有人找到解决方案或解决方法
这个问题？
3rd time posting this as the first two simply disappeared!
Here''s the issue:
We currently run an Access application in the West Coast for tracking
resource centric data. For those located in the West the program zips
along fine but the folks in the East Coast are having a nightmarish
performance issue.
We''ve had our tech guys take a look and it''s due to the network speed
across a long distance and there''s nothing much that can be done.
We''ve minimized the number of hops and we''re practically on the network
backbone.
What were planning to do is create a copy on another server on the East
Coast. Doing this poses a serious problem for us. All the tables have
auto ID enabled so if records are created on both machines trying to
merge them just won''t be possible due to conflicting IDs since the auto
ID will sequentially select the next numeric value.
We can''t create a replicated version as we''ll have the same network
performance issue. Has anyone found a solution or a workaround for
this problem?
这篇关于合并具有冲突的唯一键值的数据库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
