在后端 ms access 数据库中使用自动编号作为主键的表是否存在问题?
我在办公室继承了一个 MS Access 数据库,该数据库被网络上的几个人大量使用。这会导致许多数据冲突和锁定问题。我想拆分数据库,以便每个用户都有自己的前端应用程序并在服务器上维护核心数据。
其中几个表使用 autonumber:sequence:long 作为主键 - 在研究如何执行拆分时,我遇到了几篇文章,暗示这可能会在分发数据库时导致问题,但我找不到任何内容坚硬的。问题似乎是用户可以开始新记录并接收下一个自动编号,但第二个用户可以在短时间内创建新记录并接收相同的自动编号,从而导致错误?
Jet 是否正确处理此问题,或者 FE/BE 数据库是否存在自动编号问题?如果这是一种不太可能但有可能发生的情况,我确信它仍然比我的用户当前遇到的情况要好得多,但我想知道是否有办法可以最大程度地减少此类问题。
感谢您的帮助!
I inherited an MS Access database at my office that is heavily used by several people over the network. This causes many issues with data collisions and locks. I want to split the db so that each user has thier own front-end app and maintain the core data on the server.
Several of the tables use an autonumber:sequence:long as thier primary key - in researching how to perform the split I've come across several posts that hint this can cause issues when distributing a database but I haven't been able to find anything solid. The issue seems to be that a user can begin a new record and receive the next autonumber but a second user can create a new record within a short interval and receive the same autonumber resulting in an error?
Does Jet handle this correctly or are there autonumber issues with a FE/BE database? If it's an unlikely-but-possile occurance I'm sure it will still be much better than what my users are currently experiencing but I'd like to know if there are ways I can minimize such issues.
Thanks for your help!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我年轻时曾不幸使用过许多 Access 数据库。虽然 Access 存在很多问题,但我不知道在拆分数据库、多用户环境中是否遇到过自动编号列问题。它应该工作正常。这是一个非常常见的设置,如果出现问题,整个互联网上都会有关于它的帖子。
I've had the misfortune of working with many Access databases in my youth. While there are many issues with Access, I do not know if I've ever run into a problem with AutoNumber columns in a split database, multi-user environment. It should work fine. This is such a common setup that there would be posts all over the Internet about it if were an issue.
只要您不进行数据复制(即多个订阅者数据库,用户可以在同一表中但在不同位置插入新记录),则使用自动编号作为主键就不会有问题。
如果您认为有一天您可能需要进行复制(不同位置,一个中央数据库),请毫不犹豫地切换到唯一标识符(复制 ID)。
As long as you are not going for data replication (ie multiple subscriber databases, where users can insert new records in same tables but in different locations), you will not have problems with autonumbers as primary keys.
If you think that one of these days you might need to go for replication (different locations, one central database), do not hesitate to switch to unique identifiers (replication IDs).
您对分裂的过程似乎有些困惑。当您这样做时,您最终会得到多个前端,但后端仍然是单个文件。因此,数据表在自动编号方面与拆分应用程序之前的数据表没有任何区别。
There seems to be some confusion on your part about the process of splitting. When you do so, you end up with multiple front ends, but the back end is still a single file. Thus, there's no difference at all for the data tables in terms of Autonumbers from what you had before you split the application.
我遇到了同样的问题,不过我做了一个解决方法,从 Onload() 事件中获取自动编号工作
我所做的是:
-Your_Table 为空,然后将值“1”分配给 Your_field
-Your_Table 包含没有缺失数字的数据,然后将值 =“行数 + 1”分配给 Your_field (1,2,....,n+1)
-Your_Table 缺少数据 (1,3,4,5,7) [注意“#2 和 #7 丢失]”,然后使用函数在 Your_Table 中搜索缺少的字段并将第一个缺失值分配给 Your_Field(本例中为 #2)
这是我发现的用于获取特定表上缺失值的函数,我再也找不到它了,但感谢成功了。
I had the same problem, nevertheless i did a workarround to get the autonumbering work from an Onload() Event
What I did is :
-Your_Table is Empty, then assigns the value "1" to Your_field
-Your_Table is has data without missing numbers,then assigns the value = "Count of lines + 1" to Your_field (1,2,....,n+1)
-Your_Table has missing data (1,3,4,5,7) [Note "#2 and #7 are missing]", then uses a function to search in Your_Table the missing fields and assign to Your_Field the first missing value (#2 in this example)
Here is the function that i found to get the missing values on an specific table, i cant find it anymore, but thanks for the one who made it.