1

我是我公司中试图解决冷融合错误和错误的人。我们每天都会收到包含冷融合错误等详细信息的电子邮件，并将这些信息存储在我们的数据库中。

对于 ColdFusion 中的一些不同应用程序，它们似乎偶尔会产生“违反 PRIMARY KEY 约束”错误。

在代码中，我们总是在尝试插入之前检查数据库中是否存在一行，但它仍然会产生那个错误。

所以我的想法是，要么我们需要围绕这些检查、插入或更新块进行 cftransaction。但我不确定这是否能真正解决问题。

这些以标准冷融合风格/框架编码。这是一个伪代码示例。

cfquery name="check_sometable" datasource="#dsn#" select id from sometable /cfquery

if check_sometable.recordcount gt 0 -do insert else -do update /endif

那么为什么这会间歇性地导致主键违规呢？

这是一个 sql server 问题，我们是否缺少配置选项？

我们得到所有这些是因为我们没有使用 Coldfusion 8 标准的最新热修复版本吗？

我们是否需要升级我们的 jdbc/odbc 驱动程序？

谢谢你。

4

1 回答 1

4

Sounds like race conditions to me. Two connections check for the next available id at the same time, get the same one and then the insert fails on the second one. Why are you not using an identity field to create the PK if it is a surrogate key?

If you have a PK that is a natural key, then the violation is a good thing, you have two users trying to insert the same record which you do not want. I would try to fail it gracefully though, with an error that says someone else has created the same record. And then ask if they want to update it after loading the new values to their screen. I'm not sure I would want it to set up so that the data is automatically updated by the second person without them seeing what the first person put into the database.

Further this might be an indication that your natural key is not as unique as you think it is. Not sure what this application does, but how likely is it that two people would want to be working with the same data at a the same time? So if your natural key were something like company name, be aware that they are not guaranteed to be unique and you might have users overwriting good data for one company with data for another company already. I've found in life there are truly very few really unique, never changing natural keys. So if your natural key really isn't unique, you may already have bad data and the PK violations are just a symptom of a differnt problem not the real problem.

于 2010-12-20T16:34:38.507 回答