写冲突困境 [英] Write Conflict Woes

问题描述

下午好，Byte''rs！


我正在烦恼，利用我的框架，一直让我感到悲痛。简而言之：


-Access 2003编译的ADE应用程序

-SQL Server 2005后端

-15并发用户

通常我们的应用程序具有非常特定的工作流程，可以处理用户如何分配他们负责更新的特定记录。这很好用，因为它将标准推送到在服务器上运行的存储过程，抓取可用记录并将它们放在用户的管道中。


但是，我们已经遇到需要我们绕过这个过程的情况，并手动为我的用户分配记录（通过分配，这意味着用应用程序用于工作流程的首字母更新文本字段）。


我们遇到的问题是，如果两个用户进入打开状态，管道手动获取记录，如果两个用户抓住相同的记录并开始制作udpates，当第二个人去更新时他们会收到写冲突错误。


我正试图找到一种方法来获取Accesslook在输入任何更改之前查看记录是否已更新，但如果没有一个主LOCK / UNLOCK按钮将锁定状态存储在一个单独的锁定表中，我就会空着。


有什么建议吗？ ：）

Good afternoon, Byte''rs!

I''m running into an annoyance that, utilizing the framework I am, has been causing me grief. In a nutshell:

-Access 2003 Compiled ADE application
-SQL Server 2005 backend
-15 concurrent users

Normally our application has very specific workflows that handle how users get assigned specific records they''re responsible for updating. This works well, because it pushes criteria to a Stored Proc that runs on the server, grabbing available records and putting them in a user''s pipeline.

However, we''ve come across a situation that required us to bypass this process, and assign records to my users manually (by assigning, that means updating a text field with their initials which the application uses for workflow).

The problem we''re having is that if two users go into the "Open" pipeline to manually grab a record, if two users grab the same record and start making udpates, when the second person goes to update they recieve the write conflict error.

I''m trying to come up with a way to have Access "look" to see if the record is updated before any changes are entered, but short of having a master LOCK / UNLOCK button that stores the locked status in a separate locking table, I''m coming up empty.

Any suggestions? :)

推荐答案

我想不是通过管道来理解你所指的是什么。导致我发现这个问题有点令人困惑。


它是一个标准的链接表吗？


你的结构如何组合在一起（a简要说明请？）

I guess not understanding what you are referring to by "pipeline" is causing me to find the question a bit confusing.

Is it a standard linked table?

How does your structure fit together (a brief explanation please)?

是的，对不起。


管道是一个用户的队列，它基本上是一个记录集下拉到应用程序中的特定标准，无论用户选择什么（通常是这样的，给我数据集1，数据集2，其中assign_box是我的首字母缩写。


在这种情况下，我已将表连接在一起。更新仅应用于右表（使用LEFT JOIN），该表是从存储过程创建的，并且该SP用作表单的记录源。


所以基本上我要做的就是阻止两个用户修改同一条记录。

Yeah, sorry about that.

The "pipeline" is a user''s queue, it''s basically a recordset pulled down into the application for specific criteria, whatever the user selects (usually something like, "give me data set 1, data set 2, where the assign_box is my initials").

In this case I''ve got tables joined together. Updates are only being applied to the Right table (using a LEFT JOIN) that''s created from a stored procedure and that SP is used as the record source of the form.

So essentially what I''m trying to do is prevent two users from modifying the same record.

也许我还没有得到什么。


如果您提供每个人看到的管道数据的SP控制发送哪些数据，可能是因为每条记录仅由一个人拥有，那么它如何同时发送相同的记录两个不同的请求者？


即使假设这不是按预期工作，那么这肯定是SP的一个问题，而不是项目的Access部分。

也许你可以解释我错过的东西。它可以简单地说是整个画面。当然，但是让我们看看我们能得到什么。

Maybe I''m still not getting something.

If your SP that provides the data for the pipeline as seen by each individual is in control of which data is sent, presumably on the basis that each record is only owned by one individual, then how can it send the same record concurrently to two different requestors?

Even assuming this is not quite working as expected then surely this is a problem with the SP rather than the Access portion of the project.

Maybe you can explain what I''m missing. It may be simply "the whole picture" of course, but let''s see where we can get.

这篇关于写冲突困境的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！