IS.UUID.V4: UUID V4 Random Generation
A Universally Unique Identifier (UUID) is an identifier standard used in many non-MultiValue databases and software to generate a Unique ID outside of using incremental numbers. A UUID is simply a 128-bit unique value that can be expressed as either a larger number or a string.
The common format for a UUID is a string format that looks like the following:
123e4567-e89b-12d3-a456-426655440000
The intent of a UUID is to generate an ID that can be used across different databases, and will always be unique. This is different from a sequential number that would only be unique in the file or table itself, and not across files, accounts, or databases.
There are several different versions of UUID. This article is based around the Version 4 of the RFC 4122 specification for UUIDs. Version 4 is used to generate a Unique ID based on random number generation.
Version 4 is also commonly referred to as a GUID. While a GUID doesn't follow the same specification as UUIDs, it is the same basic format.
About Random UUID
Random Generation of UUIDs has a flaw in it that a software developer will need to handle on their own. Since this UUID is based around a randomly generated value, and not a sequential or managed value, there is NO guarantee that the value being generated will be unique within the file, table, or database.
All a Version 4 UUID does is generate a UUID string in the 8-4-4-4-12 format. There is high likelihood that the UUIDs generated in small batches will be unique, but since MultiValue BASIC uses a pseudo-random generate, you can't guarantee you won't generate the same UUID more than once.
Generating the Random Number
Some of the algorithms that I've seen in other SDKs generate a large random number and then encode that random number into the 8-4-4-4-12 format. I chose to do it a little different.
Instead of generating a single large random, I chose to create sixteen random numbers between one and two hundred fifty-five. This was easier and didn't cause any BASIC runtime overflow errors.
I then converted those sixteen random numbers into a HEX string in the 8-4-4-4-12 format.
Conforming to RFC 4122 Specification
There is one last thing that needs to be done to make this a valid RFC 4122 value. There are 2 values that must be something specific:
Set the four most significant bits of the 7th byte '0100', so that the Hex value always starts with a 4,
Set the 2 most significant bits of the 9 th byte to '10', so that the Hex value will always start with a 8, 9, A , or B.
AA97B177-9383-4934-8543-0F91A7A02836
^ ^
1 2
This is all done using BITAND and BITOR. To keep this program generic, I chose to use Bit math to do the logical AND and OR, instead of the built-in BITAND and BITOR found on some systems.
The code to replicate the Logical AND and OR was borrowed from Dave Meagher's code found in the FOSS4MV/mvCrypt code on BitBucket:
https://bitbucket.org/foss4mv/mvcrypt
Example
FOR I = 1 TO 100 CALL IS.UUID.V4(UUID,ERROR) CRT UUID : " Error: " : ERROR NEXT I
Output
25A8FC2A-98F2-4B86-98F6-84324AF28611 Error: 0 81F8D30C-C12F-44BD-A299-2F9BC67B9945 Error: 0 4A768B81-6928-496C-81BE-E2AA107A0126 Error: 0 2DC77B85-5819-46A6-BCDE-C34CE6A6562D Error: 0 45AC3202-9353-4B91-A7EF-9B876C7F706F Error: 0 77029FEF-3818-489F-899E-EB49221E02E4 Error: 0 ED21503F-4AF9-413F-ABF4-9FB1E507D974 Error: 0 36F94C73-F0EB-43A9-AB69-676D219878CD Error: 0