从 MS Access 使用 SQL Server GUID 的建议答案

【问题标题】：Recommendations on using SQL Server GUID from MS Access从 MS Access 使用 SQL Server GUID 的建议
【发布时间】：2008-12-26 01:54:09
【问题描述】：

我正在将现有的 MS Access 后端升级到 SQL Server 2008，并且因为我们想使用 SQL Server Merge replication，所以我必须将所有当前的主键（当前标准的自动增量整数）更改为 GUID。

以下是问题：

【问题讨论】：

您在使用 Access 吗？你说你从 Jet 升职，但这并不意味着 Access 参与其中。如果您的前端在 Access 中，那么处理 GUID 会出现重大问题：trigeminal.com/usenet/usenet011.asp?1033。
大卫，你应该发布一个答案而不是评论，我会给你+1作为参考。使用 GUID 是有问题的，但这不是一个无法克服的问题，就我而言，我认为 GUID 是相当强制性的......

【解决方案1】：

Chris 说得对（1）合并复制不需要 GUID 和（2）只有一种 GUID 类型，但您必须知道：

GUIDS 可以按照不同的规则生成。你可以检查这个here
设置复制时，SQL 会系统地添加一个 GUID （作为 newsequentialid 生成）到每个表（如果还没有）存在，并将其称为rowguid。当然，如果每个表中已经有这样的 GUID/newSequentialId，SQL 会使用它。但是我不建议您将复制 GUID 与 PK GUID 混合使用：您可以将 GUID 类型的所有主键声明为“newSequentialIds”，但是（a）您将失去在客户端生成 GUID 值的可能性- 见下文 - 并且 (b) 你的 PK 将是“可预测的”，这个想法让我感到不舒服......
保持自动增量整数并通过复制管理它们的范围意味着大量开销（您必须为每个表/每个发布分配范围），并且在从不同来源复制时可能会产生冲突。
此外，像this one 这样特定于范围分配的一些 SQL 错误仍然没有得到妥善解决：应用累积包 5 并没有解决我们的问题，我们必须找到另一种方法来重新启动复制过程。李>
无论如何，我深信从整数切换到 GUID 作为主键是强制性的。造成这种情况的原因有很多，其中一个与这些范围管理有关，可能是头痛和通宵故障排除的潜在来源。

关于从整数到 GUIDS 的变化，我建议您编写一个循序渐进的模块，它将：

花点时间编写这段代码。在它正常工作之前，您将多次使用它。您应该利用 DAO 对象、tabledef、索引等。请记住，您必须始终能够返回到起点，因此不要忘记初始备份过程。

如何从 VBA 操作 GUID？有几点需要了解：

GUID 属于 Variant 类型
在应用程序的客户端生成您的 GUID 作为主键是可能且容易的，正如我曾经建议过的那样 here。
当您尝试获取 GUID 值时从表单中的控件（通常作为组合框中的链接字段），您将获得 '?????' 但没有价值。您必须参考记录集中的字段值才能获得正确的数据。您可以在您的应用中打开这样的表单，转到“立即”窗口，然后尝试以下操作：

? myForm.myControl
?????

? myForm.recordset.fields("myFieldName")
{000581EB-9CBF-418C-A2D9-5A7141A686CC}

myFirstRecordset.FindFirst "stringFromGUID(myGuidId) = " & StringFromGUID(mySecondRecordset.Fields("myGuidId").Value)

【讨论】：

【解决方案2】：

这可能有点离题。但是，您不必使用 GUID 来执行合并复制。您仍然可以使用自增整数并将不同的范围分配给不同的数据库实例。这样就不会生成具有相同 ID 的行。

另外，SQL 2008 中只有一个 GUID 类型字段 - uniqueidentifier

【讨论】：

好吧，对于整数，我仍然可以这样做，但对于 GUID 类型，我指的是它们的生成方式：我读过推荐使用 newsequentialid()，但我想记住有一些潜在的问题，虽然我不记得我在哪里读到的。