The problem is that you can't store a GUID in an integer: a standard int is an Int32 - a 32 bit number, so it can store values from −2,147,483,648 to 2,147,483,647. A GUID is a unsigned 128 bit number, so it can store from 0 to 340,282,366,920,938,463,463,374,607,431,768,211,455 - which obviously won't fit! As a result, you waste the whole advantage of using a GUID: that it is extremely unlikely to be be duplicated. Unlike database IDENTiTY fields, a GUID is not a "regular sequence" of numbers such that if you use two in quick succession you get values which differ by one - with GUIDs you get values that are wildly different!
If you want to use integer ID's then use integers throughout - don't try to assume that it's a "valid guid".
If you want to use GUID ids, then use GUIDs throughout - dont; try to store them in any other format.
Quote:
My DB Table fields are UserID, Username, Password and Email
In this fields
UserID is an integer datatype
Username is an varchar datatype
password is an varchar datatype
email is an varchar datatype
Three other things to do:
1) Check other tables first before you change anything - if they contain foreign keys to the old ID, then you need to add a column to that tables as well and copy the "new GUID ID" into them or you will lose the connection.
2) Never store passwords in clear text - it is a major security risk. There is some information on how to do it here:
Password Storage: How to do it.[
^] It's considered a
Code Crime[
^]
3) Use NVARCHAR instead of VARCHAR - it uses Unicode instead of ASCII, which matches to .NET code (which is all Unicode) ASCII is a much smaller set of characters, and some usernames may not work at all if you store them an VARCHAR fields. You should also consider emails as Unicode as it has been allowed since 2012.