OriginalGriff
Проблема в том, что вы не можете хранить GUID в виде целого числа: стандартный int - это Int32-32-битное число, поэтому он может хранить значения от -2,147,483,648 до 2,147,483,647. GUID - это беззнаковое 128-битное число, поэтому он может хранить от 0 до 340,282,366,920,938,463,463,374,607,431,768,211,455-что, очевидно, не подходит! В результате вы теряете все преимущество использования GUID: он крайне маловероятен для дублирования. В отличие от полей идентификации базы данных, GUID не является "регулярной последовательностью" чисел, так что если вы используете два в быстрой последовательности, вы получаете значения, которые отличаются на единицу - с GUID вы получаете значения, которые дико отличаются!
Если вы хотите использовать целочисленные идентификаторы, то используйте целые числа повсюду - не пытайтесь предположить, что это "действительный guid".
Если вы хотите использовать идентификаторы GUID, то используйте GUID повсюду - не делайте этого; попробуйте сохранить их в любом другом формате.
Цитата:
Поля моей таблицы БД-это UserID, имя пользователя, пароль и электронная почта
В этой области
UserID is an integer datatype
Username is an varchar datatype
password is an varchar datatype
email is an varchar datatype
Нужно сделать еще три вещи:
1) Сначала проверьте другие таблицы, прежде чем что - либо менять-если они содержат внешние ключи к старому идентификатору, то вам нужно добавить столбец к этим таблицам и скопировать в них "новый идентификатор GUID", иначе вы потеряете соединение.
2) Никогда не храните пароли в открытом тексте - это серьезная угроза безопасности. Здесь есть некоторая информация о том, как это сделать:
Хранение паролей: как это сделать.[
^] Это считается ...
Криминальный Кодекс [
^]
3) Используйте NVARCHAR вместо VARCHAR - он использует Unicode вместо ASCII, что соответствует .Чистый код (который весь состоит из Юникода) ASCII-это гораздо меньший набор символов, и некоторые имена пользователей могут вообще не работать, если вы храните их в полях VARCHAR. Вы также должны рассматривать электронную почту как Unicode, поскольку это было разрешено с 2012 года.
Member 8583441
Ладно, хорошо, но у меня есть идентификационный номер в базе данных, извлекающий его из базы данных. Значение идентификатора хранится в целочисленном формате, поэтому я подумал, что нужно изменить значение с целочисленного на формат Guid, чтобы он также мог быть доступен на следующих страницах.
Тогда определенно я изменю тип данных поля id но не могли бы вы дать некоторое объяснение по этому поводу чтобы изменить его на Guid из interger в SQL Server 2012
OriginalGriff
Вы упускаете главное: вы не можете хранить значение GUID в целочисленном виде, там нет ничего похожего на достаточное пространство. И GUID-это не "просто случайные числа" - у них есть структура и определенный набор алгоритмов генерации, которые производят числа, которые просто не помещаются в 32 бита!
Если вы храните его в БД в виде целого числа, то это не GUID, а скорее поле идентификатора.
Как выглядит ваша таблица БД?
OriginalGriff
Если у вас есть строки там, то вы не можете - нет никакого механизма для преобразования целых чисел в GUID (по причинам выше).
Вам нужно будет добавить новый столбец ID, установить его в GUID и установить его значение по умолчанию в NEWID(). Сохраните таблицу.
Отредактируйте его еще раз, переместите первичный ключ, если это необходимо, и удалите старый столбец идентификатора.
(Причина двухэтапного подхода заключается в том, чтобы избежать ситуации, когда таблица может иметь одинаковые строки, что является плохой идеей в SQL).