Реята, спасибо за советы. Но лучший советчик - ясная, выспаная голова.
Давайте я подробно расскажу с чем имею дело. Просто, чтобы топик был законченным.
Тестовый запрос на стороне mssql:
1.
2.
3.
select UUID, cast(UUID as char(16)), NAME
from SP_STOCK
where NAME='__Мебель_Склад гот.продук'
Получаем:
0xB22A2C768A5115E011E325A8E322A49D
__Мебель_Склад гот.продук
Тип первого столбца - binary(16). При выводе на экран мы видим HEX-представление.
Второй столбец - натуальное значение. Пришлось постараться поискать строку, которая бы не содержала откровенно непечатных символов.
Этот вариант отлично засосется в Firebird посредством FibPlus компонентов. Подробности в стартовом сообщении.
Если ASCII-представление UUID (второй столбец) содержит непечатный символ, то при передаче часть значения теряется. Не теряется, если приемник - столбец BLOB. Но как оказалось, текстовые блобы (TFIBMemoField кажется) в Delphi не могут работать в lookup-связках, а т.к. перекачивается справочник и обсуждаемое поле - суть ID, то лукапом ему работать на роду написано. Причем в гридах, что затрудняет подстановку костылей (своя форма подбора значения из справочника).
Далее я был несколько обескуражен тем, как работает функция uuid_to_char в firebird:
1.
2.
select uuid_to_char('І*,vЉQаг%Ёг"¤ќ')
from rdb$database
получаем:
B22A2C76-8A51-15E0-11E3-25A8E322A49D
Если присмотреться, то это просто строка от HEX-представления и черточки для красоты. Возможно так всё и задумывалось, но я просто был сбит с толку, что
1.
cast(UUID as UNIQUEIDENTIFIER)
на стороне mssql выдает другую строку:
762C2AB2-518A-E015-11E3-25A8E322A49D
Интересно, что последние две части квинтета совпали, вторая и третья части тоже совпали, но в них переставлены местами байты, а первая часть тоже совпала, но буковки перемешаны там просто адски, хотя и теже самые. :)
Под конец добил 1Сник, который показал как он может преобразовывать код в 1C-объект:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
УИД = "B22A2C76-8A51-15E0-11E3-25A8E322A49D";
УИД = НРЕГ(СтрЗаменить(УИД,"-",""));
УИД1 = Прав(УИД,8 );
УИД2 = Сред(УИД,21,4);
УИД3 = Сред(УИД,17,4);
УИД4 = Лев(УИД,4);
УИД5 = Сред(УИД,5,12);
УИД = УИД1 + "-" +УИД2 + "-" + УИД3 + "-" + УИД4 + "-" + УИД5;
Склад = Справочники.Склады.ПолучитьСсылку(Новый УникальныйИдентификатор(УИД));
Сообщить(УИД);
Сообщить(Склад);
Результат:
1.
e322a49d-25a8-11e3-b22a-2c768a5115e0
__Мебель_Склад гот.продук
Я совершенно не въехал, что за третий GUID-подобный объект у него родился (e322a49d-25a8-11e3-b22a-2c768a5115e0) и почему он оказался непохож ни на mssql-guid (762C2AB2-518A-E015-11E3-25A8E322A49D), ни на HEX-представление, оно же результат птичкиного uuid_to_char (B22A2C76-8A51-15E0-11E3-25A8E322A49D).
Но с практической точки зрения дальше вроде всё стало ясно:
- 1Сника устроит на входе HEX;
- значит на стороне firebird будем хранить HEX в виде CHAR(32);
- значит на стороне mssql нужно получать это HEX в виде строки (сейчас это binary, которая только выглядит как HEX).
Последнее решилось с помощью гугла:
1.
convert(char(32), UUID, 2)
B22A2C768A5115E011E325A8E322A49D
И к черту эти char(16) character set octets: перепахивать библиотеку ради корректной записи/чтения через AsString смысла не вижу. А вот mssql похоже теперь потеть больше, т.к. выборки из приложения теперь ему делать не через
, а через
1.
where convert(char(32), UUID, 2) = :UUID
Но как пелось в детской песенке:авторПозабыты хлопоты, остановлен бег -
Вкалывают роботы, а не человек.:)
p.s. Не сомневаюсь, что суровая жизнь и тут меня хлопнет по шапке, как это было вчера с блобами. Но пока вроде выглядит всё по рабочему... хоть и не особо энтерпрайзненько
