Question

I have the following t-sql code which I have converted to c#.

DECLARE @guidRegular UNIQUEIDENTIFIER, @dtmNow DATETIME  

 SELECT @guidRegular = '{5bf8e554-8dbc-4008-9d48-5c6e0a4d28d7}'  

 SELECT @dtmNow = '2012-02-09 18:31:38' 


print (CAST(CAST(@guidRegular  AS BINARY(10))  +  CAST(@dtmNow AS BINARY(6))  AS UNIQUEIDENTIFIER)) 

When I execute the .net version of the code (using same Guid and DateTime) I Get a different guid? It looks like it has something to do with the datetime element can anyone help ?

c# extension code:

using system.data.linq;
...
...

   public static class GuidExtensions
    {
        public static Guid ToNewModifiedGuid(this Guid guid)
        {
            var dateTime = new DateTime(2012,02,09,18,31,38);
            var guidBinary = new Binary(guid.ToByteArray().Take(10).ToArray());
            var dateBinary = new Binary(BitConverter.GetBytes(dateTime.ToBinary()).ToArray().Take(6).ToArray());

            var bytes = new byte[guidBinary.Length + dateBinary.Length];
            Buffer.BlockCopy(guidBinary.ToArray(), 0, bytes, 0, guidBinary.ToArray().Length);
            Buffer.BlockCopy(dateBinary.ToArray(), 0, bytes, guidBinary.ToArray().Length, dateBinary.ToArray().Length);

            return new Guid(bytes);
        }
    }

Answer 1

I’m not surprised that SQL and .net would have different binary representations of a date/time. I would be surprised if they had.

Your c# code is asking the DateTime structure to serialize a value to a 64-bit ( 8 byte) byte array that can be used to recreate the same value. Then you’re throwing away 2 bytes (the year? the millisecond? a checksum? who knows?)

Your sql code is asking the sql engine to take it’s internal representation of a datetime – which is also 8 bytes – throw away two, and give the result.

So:

1. If you want identical values, you would need to stop relying on the internals of how a datetime is stored / serialized. Convert it to 6 bytes using a repeatable method you can write in both .net and tsql
2. Realize that you are removing the 6 bytes of a guid that represent the spatially unique portion and replacing them with the time. So you are creating a GUID that has the time encoded twice, and are greatly increasing the odds of duplicate GUIDs being created.

Of course, this ignores the more glaring issue of “why would anyone want to do that?” I’m going to assume that it’s some really brilliant subsystem, instead of the more likely explanation that somebody is desperately trying to solve the wrong problem.