【问题标题】:UniqueIdentifier to GUID join failure唯一标识符到 GUID 加入失败
【发布时间】:2014-02-28 17:48:08
【问题描述】:

我有一个很大的查询抛出了一个错误,我已将其缩减为相当小的块。

SELECT
    Reconciliation_Receiving.UserId, *
FROM
    Reconciliation_Receiving 
    LEFT JOIN Profiles.dbo.UserObject ReceivingUser ON Reconciliation_Receiving.UserId = ReceivingUser.g_user_id

抛出的错误是“从字符串转换为唯一标识符时转换失败。”

该错误似乎与 UserObject 和 Reconciliation_Receiving 之间的 LEFT JOIN 相关,因为如果我删除它,查询就会执行。

Reconciliation_Receiving.UserId 是 UNIQUEIDENTIFIER,而 ReceivingUser.g_user_id 是 GUID(nchar(38))。我认为这种差异可能是相关的,但我不知道究竟是什么。据我所知,两者都有有效的指导作为数据(尽管这可能是错误的,并且是我将继续研究的一种途径。)我正在研究的特定案例有一个 WHERE 子句(为简洁起见省略) 其中所有 Reconciliation_Receiving.UserId 值都是 NULL...但我猜坏数据可能在其他地方,因为我的理解是连接是在 WHERE 过滤完成之前完成的。

我尝试搜索存储在 UserObject 列中的数据的长度,以查看是否有一些不良数据以某种方式存储在那里,但没有跳出来。

也就是说,数据可能有什么问题?如何找到它?或者是别的什么?

新信息:当我尝试以下操作时:

SELECT CAST(g_user_id AS uniqueidentifier) 
FROM Profiles.dbo.UserObject

它开始打印一些值,然后 bam,同样的错误。所以我肯定在考虑坏数据。但仍然不知道如何真正找到它。

【问题讨论】:

  • 可能是CAST(ReceivingUser.g_user_id AS UNIQUEIDENTIFIER)?
  • @MichaelPerrenoud 有趣的是,我只是在尝试这个......我将添加一些信息......
  • 您当然可以将左侧转换为 nchar(38)。这不会给你任何错误。
  • @MikaelEriksson :是的,但我担心性能,而且它只会掩盖潜在的数据问题。

标签: sql-server tsql join guid uniqueidentifier


【解决方案1】:

该消息告诉您确切的问题:无法将字符串转换为 guid。现在你知道了:a)某处有转换; b) 字符串数据不可转换。

“据我所知,两者都有有效的 guid 作为数据”

不,消息表明情况并非如此。信息非常明确。

查找无效数据。例如,像这样:

SELECT *
FROM ReceivingUser
WHERE TRY_CONVERT(UNIQUEIDENTIFIER, ReceivingUser.g_user_id) IS NULL AND ReceivingUser.g_user_id IS NOT NULL

您最好不要将 Guid 存储为字符串,而是将其存储为 UNIQUEIDENTIFIER,这样您就不会遇到这样的麻烦。

【讨论】:

  • 嗯,是的。这就是为什么我说“据我所知”,然后继续说这仍然是我正在关注的领域。不幸的是,我无法更改数据类型。正如我所提到的,我怀疑数据不好,但不知道如何找到它。有趣的是,我终于找到了您提供的相同解决方案(因此您得到了支票和上涨)。我没有想到 GUID 类型会允许非十六进制字符。事实证明确实如此,而且显然有人直接在数据库中乱搞数据,并在 guid 中添加了一些坏字符。 Grr。谢谢!
  • (对于它的价值,我绝对同意你的看法......他们应该是 UNIQUEIDENTIFIERs......这就是为什么我的部分,接收用户部分,是这样的。不幸的是,GUID 列是另一个不可改变的系统的一部分......所以我有点坚持差异。)
猜你喜欢
  • 2010-11-28
  • 1970-01-01
  • 1970-01-01
  • 2011-08-29
  • 1970-01-01
  • 1970-01-01
  • 2018-11-24
  • 2016-10-18
  • 1970-01-01
相关资源
最近更新 更多