Interesting, Mike.
Have you sent that into SV support? Hopefully, that is something they would jump on right away to fix.
I tested with 11 13505 and it does not happen with that version…
StringTheory uses Random in the generation of Guids. Since random seeds from the time this worked fine.
Until one enterprising programmer had a process that started multiple child exes in the same centisecond.
So now StringTheory initialises the random number using a combination of the time, and process id. So if you run the above test after calling st.random, itll be fine even on the noted build.
The short version is that all uuids are 128 bits long. The ones you are familiar with on MS platforms are typically displayed as hex-encoded (32 nibbles plus some hyphens).
While stringtheory has a method for generating version 4 uuids, for general use it prefers to use a ASCII value in 16 chars, which represents around 80 bits of entropy.
This is sufficient for the main use case (unique per table) and can be generated on any platform, in any language. Its also visible and editable in readers (like topscan) without encoding or decoding. It also does not need encoding in text formats like CSV, JSON or XML. It can even be used (and generated) in Excel and so on.
It’s fundamentally suitable for two use cases.
A) replacing auto-numbering (client or server side) and so bypassing all the problems that auto numbering has.
B) data distribution - allowing data to exist in multiple databases (including sql, isam, and text) at the same time.
C) compatible with all platforms and all languages. (Although generating version 4 uuids is not hard, it can be tricky because of the embedded version number.)