Проблема при работе с полями типа GUID в FibPlus через Variant [сообщение #1602] |
Mon, 13 February 2023 14:10 |
jonikDk
Сообщений: 5 Зарегистрирован: August 2022
|
Junior Member |
|
|
Нужно на клиенте было прочитать данные из одной таблицы и записать в другую
Поля и параметры читалиcь через Value (Variant)
И обломался на чтении поля guid (CHAR(16) CHARACTER SET OCTETS COLLATE OCTETS), при чём не на всех guid. Обломался в том плане, что источник не совпал с получателем. Очень удивился.
Вот один из проблемных guid: 12C472DA-A5FA-7A46-A666-68F7FB1BA920. Это исходный guid. В источнике получается DA72C412-FAA5-467A-A666-68F7FB1BA900
Что делать я более менее представляю. Править исходники
метод
function TFIBXSQLVAR.GetAsVariant: Variant;
или вообще
function TFIBXSQLVAR.GetAsAnsiString: Ansistring;
глубоко ещё не смотрел.
Вдруг кто сталкивался и делал похожие изменения. От помощи не откажусь. Потому что изменения надо ещё протестить будет, а это время и ошибки.
[Обновления: Mon, 13 February 2023 14:12] Известить модератора
|
|
|
|
|
|
|
|
Re: Проблема при работе с полями типа GUID в FibPlus через Variant [сообщение #1609 является ответом на сообщение #1602] |
Mon, 13 February 2023 18:07 |
shalamyansky
Сообщений: 150 Зарегистрирован: August 2022
|
Senior Member |
|
|
jonikDk писал(а) Mon, 13 February 2023 14:10
12C472DA-A5FA-7A46-A666-68F7FB1BA920
DA72C412-FAA5-467A-A666-68F7FB1BA900
Забавное превращение. Первая четверка байт и следующие две пары зеркально отразились, в то время как последняя восьмерка осталась неизменной (в последнем байте описка, скорее всего). Очень похоже, как если бы данные легли в структуру, первая половина которой объявлена как числа, а вторая - как строка или набор байт. При этом "зеркальную" половину сперва записали как числа, а прочитали, как байты, или наоборот.
|
|
|
|
|
|
|
|
|
Re: Проблема при работе с полями типа GUID в FibPlus через Variant [сообщение #1616 является ответом на сообщение #1609] |
Tue, 14 February 2023 13:23 |
jonikDk
Сообщений: 5 Зарегистрирован: August 2022
|
Junior Member |
|
|
shalamyansky писал(а) Mon, 13 February 2023 18:07jonikDk писал(а) Mon, 13 February 2023 14:10
12C472DA-A5FA-7A46-A666-68F7FB1BA920
DA72C412-FAA5-467A-A666-68F7FB1BA900
Забавное превращение. Первая четверка байт и следующие две пары зеркально отразились, в то время как последняя восьмерка осталась неизменной (в последнем байте описка, скорее всего). Очень похоже, как если бы данные легли в структуру, первая половина которой объявлена как числа, а вторая - как строка или набор байт. При этом "зеркальную" половину сперва записали как числа, а прочитали, как байты, или наоборот.
Нет, не описка, это как раз, как я понимаю основная проблема. А то что зеркально, это скорее всего мой косяк. Смешал FB и Delphi.
|
|
|
|
|
|
|
|
|
|