Home/ Questions/Q 584587
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T14:54:49+00:00

We use GUIDs extensively in our database design; Business Object properties provide Guid.Empty GUIDs

  • 0

We use GUIDs extensively in our database design; Business Object properties provide Guid.Empty GUIDs for DB null values and null is always saved to the database if the value is Guid.Empty.

Apart from Guid.Empty (00000000-0000-0000-0000-000000000000) how likely is it that a GUID will be generated with all the same characters e. g.: 11111111-1111-1111-1111-111111111111

Just considering using GUIDs like these for specific values.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In short: For GUID generated according to the published standards and specifications it simply can’t happen. A GUID has a structure and some of the fields actually have a meaning. What’s more, .NET generates GUIDs of version 4, where it absolutely can’t happen. They are defined in a way that there won’t be such a GUID. For details, see below 😉

    There are five to seven bits which are the main pitfall here. Those are the version identifier (the first four bits of part three) and the variant field specifying what variant of GUID this is.

    The version can be anything between 1 and 5 currently. So the only valid hex digits for which we could get such a GUID at this point are – obviously – 1 through 5.

    Let’s dissect the versions a little:

    1. MAC address and timestamp. Both are probably hard to coax into all-1 digits.
    2. MAC address and timestamp as well as user IDs. Same as for v1.
    3. MD5 hash. Could possibly even work.
    4. PRNG. Can’t ever work since the first digit of the fourth part is always either 8, 9, A or B. This contradicts the 4 for the version number.
    5. SHA-1 hash. Could possibly even work.

    So far we ruled out version 4 as impossible, others as highly unlikely. Lets take a look at the variant field.

    The variant field specifies some bit patterns for backwards compatibility (x is a don’t care), namely:

    0 x x Reserved. NCS backward compatibility.
1 0 x The only pattern that currently can appear
1 1 0 Reserved, Microsoft Corporation backward compatibility
1 1 1 Reserved for future definition.

    Since this pattern is at the very start of the fourth part, this means that the most significant bit is always set for the very first hex digit of the fourth part. This means that this very digit can never be 1, 2, 3 or 5. Not counting already generated GUIDs, of course. But those with the MSB set to 0 happen to be either v1 or v2. And the timestamp part of those means that they would have to be generated some millenia in the future for that to work out.

    • 0