2015-08-07 3 views
5

У меня есть таблица с именем Student, содержащая столбец StudentId как GUID, поэтому я использовал для этого тип данных Uniqueidentifier.Указание с дополнительными символами

Если я хочу, чтобы получить конкретную запись, я получаю результат, используя запрос:

SELECT * FROM Student WHERE StudentId = '919C3BF9-B081-458C-897D-C0B3FF56AF73' 

возвращает ожидаемый результат. Но в случае, если я ошибочно добавлю дополнительные символы в конце, он также возвращает тот же результат. Как и ниже запроса:

SELECT * FROM Student WHERE StudentId = '919C3BF9-B081-458C-897D-C0B3FF56AF73xyz' 

Если я прохожу дополнительные символы в конце GUID, почему не считают недействительным GUID? и вернуть тот же результат?

+0

а строка пользователя сравнить в SQL –

ответ

2

GUID 16 байт, поэтому с учетом 919C3BF9-B081-458C-897D-C0B3FF56AF73

91 является первым байтом
9C является 2-й байт
3B является 3-й байт
F9 Является четвёртой байт
..
..
..
..
56 занимает 14 байт
AF занимает 15 байт
73 16 число байт

Разбор 919C3BF9-B081-458C-897D-C0B3FF56AF73xyz Завершает перед xyz.

Итак, символы вводятся после 16-го байта, не рассматриваются.

Но если вы добавите дополнительные символы спереди, это не будет считаться действительным GUID.

Более того, когда вы запрашиваете GUID, используйте код между {}.

SELECT * FROM Student 
WHERE StudentId = '{919C3BF9-B081-458C-897D-C0B3FF56AF73}' 
+1

Чтобы добавить к этому ответу, 'uniqueidentifier' типа данных имеет более высокий тип данных приоритета, чем VARCHAR поэтому VARCHAR буквальный неявно преобразуется в UniqueIdentifier.Разбор, по-видимому, более слабый без фигурного скобки, усекающего посторонние символы в буквальном. –

+1

Дополнительные символы в фигурных скобках приводят к ошибке, однако дополнительные символы вне '{}' игнорируются и усекаются. 'SELECT CONVERT (uniqueidentifier, '{919C3BF9-B081-458C-897D-C0B3FF56AF73} EXTRA') SELECT CONVERT (uniqueidentifier, '{919C3BF9-B081-458C-897D-C0B3FF56AF73EXTRA}')' – ughai

+1

Спасибо за введение '{} 'при использовании с' guid'! –

3

Как было указано из documentation:

Следующий пример демонстрирует усечения данных, когда значение слишком велико для типа данных, которые преобразуются в. Поскольку тип uniqueidentifier ограничен 36 символами, символы, которые превышают эту длину, усекаются.

DECLARE @ID nvarchar(max) = N'0E984725-C51C-4BF4-9960-E1C80E27ABA0wrong'; 
SELECT @ID, CONVERT(uniqueidentifier, @ID) AS TruncatedValue; 

Вот набор результатов.

String          TruncatedValue 
-------------------------------------------- ------------------------------------ 
0E984725-C51C-4BF4-9960-E1C80E27ABA0wrong 0E984725-C51C-4BF4-9960-E1C80E27ABA0 

(1 row(s) affected) 
+0

У msdn даже есть аналогичный пример, описывающий тот же самый – ughai

+1

, возможно, этот пример демонстрирует: 'SELECT CONVERT (UNIQUEIDENTIFIER, '919C3BF9-B081-458C-897D-C0B3FF56AF73-This-is-extra')' - производит: '919C3BF9-B081 -458C-897D-C0B3FF56AF73' – Tanner