Hello Adriano, > Can you say, with less words and more examples, what's wrong and why? > > I mean, please run the current code and dump some commands, results and > explanations here.
With the current 2.5.2 snapshot: SQL> set term #; SQL> execute block CON> returns (uuid char(16) character set octets, CON> data3 char(2) character set octets) CON> as CON> declare teller int = 12; CON> begin CON> while (teller > 0) do CON> begin CON> uuid = gen_uuid(); CON> data3 = substring(uuid from 7 for 2); CON> suspend; CON> teller = teller - 1; CON> end CON> end# UUID DATA3 ================================ ====== 07FC7A3D439ABE4DA6157509C184F747 BE4D D9CD5D4BB6C62E43A60828593046AECC 2E43 D79E9F3953F59649AFB93D1032BF7E2B 9649 E6F16F0930FBCC46B97F46B96095142B CC46 5D5334959E3CCB42B514BE2B53093240 CB42 C51795D2EBD31548A0D05565A1373C0B 1548 A4188D7AAC9B164DB530F2A0504AE5F3 164D DAD94098E1C4D548B5D352C68C8032B9 D548 448722E02944B74C8596B1A8CDE3FF0E B74C F86B644E5E2857449370F0151B648171 5744 CD37A31C39B57B4BA1C0F9EDC62D94A7 7B4B 64534A5992E1504E91526835CC47BF66 504E As you can see, the version nibble (4) always ends up in the second byte of the data3 (time high and version) field. At least if you run this code on a little-endian machine! But as per RFC4122, the version number is in the most significant 4 bits of the timestamp. And RFC4122 also stipulates that - unless excplicitly specified otherwise - each field must be encoded MSB first (i.e. in network byte order). So the data in the Data3 column *should* have read 4DBE, 432E, 4996, 46CC, etc. > I didn't ignored Mark's saying "It also explicitly says that bytes > should be in network byte order (aka big-endian)" and my code was > committed after it. But the way GEN_UUID works hasn't changed. (Except that on Posix, it now inserts a version nibble instead of being completely random.) The new UUID_TO_CHAR2 function puts the Data3 field in network byte order, so if you use that on the first generated UUID above, you get: 07FC7A3D-439A-4DBE-A615-7509C184F747 This is correct, but a) it still leaves the char(16) representation non-compliant and non-transportable, and b) if GEN_UUID is fixed, you don't need UUID_TO_CHAR2 and CHAR_TO_UUID2 at all: the existing conversion functions copy the bytes one by one without any reordering, so if the input is in network byte order, then so is the output. If you want any more examples (including the conversion functions maybe), please let me know. But now I need some sleep ;-) Cheers, Paul Vinkenoog ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
