В FIb+ нет свойства AsBinary. Вот и извращаются через строки и варианты.

12C472DA-A5FA-7A46-A666-68F7FB1BA920
DA72C412-FAA5-467A-A666-68F7FB1BA900

И философское. Никогда не мог понять, зачем единый 128-битный идентификатор разделять на какие-то бессмысленные неравные по-разному представляемые части, а визуально еще и избыточными черточками нагружать. Кто-нибудь имеет соображения на этот счет?

. Длинная, захватывающая воображение история: https://en.m.wikipedia.org/wiki/Universally_unique_identifie r

jonikDk писал(а) Mon, 13 February 2023 14:10

12C472DA-A5FA-7A46-A666-68F7FB1BA920
DA72C412-FAA5-467A-A666-68F7FB1BA900

Забавное превращение. Первая четверка байт и следующие две пары зеркально отразились, в то время как последняя восьмерка осталась неизменной (в последнем байте описка, скорее всего). Очень похоже, как если бы данные легли в структуру, первая половина которой объявлена как числа, а вторая - как строка или набор байт. При этом "зеркальную" половину сперва записали как числа, а прочитали, как байты, или наоборот.

В FIb+ нет свойства AsBinary. Вот и извращаются через строки и варианты.

. В FibPlus есть AsGuid и работает отлично.
Но проблема как понять в общем случае, что в этом поле guid, а не просто Char(16)

jonikDk

. В FibPlus есть AsGuid и работает отлично.
Но проблема как понять в общем случае, что в этом поле guid, а не просто Char(16)

если там хрень, то виндовая функция GUIDFromString() вернёт FALSE.

МП

. если там хрень, то виндовая функция GUIDFromString() вернёт FALSE.

. Ага, тоже были мысли от противного сделать.

. С чего бы в поле BINARY(16) быть "String"?..

Длинная, захватывающая воображение история: https://en.m.wikipedia.org/wiki/Universally_unique_identifie r

прекрасное чтиво!
всю ночь не спал, пытаясь переварить:
"Microsoft's COM/OLE libraries, use a little-endian format, but appear mixed-endian with the first three components of the UUID as little-endian and last two big-endian, due to the missing byte dashes when formatted as a string."