|
Отображение GUID в IBExpert и Delphi
|
|||
---|---|---|---|
#18+
Есть ли "переключатель" в IBExpert, который изменяет отображение в списках поля для GUID в стандарте Delphi/MSWindows? Вопрос вырос из проблемы визуального поиска строки по GUID, хранящемся в поле Код: plsql 1. 2. 3. 4. 5.
В таблице IBExpert для поля Код: sql 1. 2.
отображается значение {30313233-3435-3637-3839-414243444546} в то время как в Delphi из этого поля получаем Код: pascal 1. 2. 3. 4.
Покопавшись в различных источниках обнаружил проблему в представлении данных Microsoft согласно википедии (Delphi просто наследовало это от Windows): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
откуда следует, что, например, первое dd слово отображает в первой позиции четвертый байт строки FUID_DB просто потому, что числа в процессорах x86 начинаются с младшего байта. Встроенная функция UUID_TO_CHAR() FB v2.5 возвращает при преобразовании байты по порядку их следования в поле FUID_DB, вследствие чего это значение именно так отображается в поле таблицы при включенной кнопке "UUID" на панели управления списком. Если преобразование при значении поля Код: sql 1. 2.
GUID и UUID еще как-то можно сопоставить, то для варианта Код: sql 1. 2.
сопоставить первые символы уже как-то проблематично. Может, я где-то пропустил флажок "Отображать UUID в стиле Microsoft? Если такого флажка нет, то можно ли его добавить или к кнопке "UUID" добавить кнопку, например, "GUID"? ПС. Уж очень не хочется вставлять в код поля перестановку байтов только для того, чтобы видеть GUID в программе и в IBExpert одинаково. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.10.2016, 15:19 |
|
Отображение GUID в IBExpert и Delphi
|
|||
---|---|---|---|
#18+
ivklmПС. Уж очень не хочется вставлять в код поля перестановку байтов только для того, чтобы видеть GUID в программе и в IBExpert одинаково. Т.е., тебе на свою реализацию GUIDToString минут пятнадцать потратить лень, а мне байты переставлять и кнопочки-галочки городить в охотку должно быть? Хм... ... |
|||
:
Нравится:
Не нравится:
|
|||
29.10.2016, 17:01 |
|
Отображение GUID в IBExpert и Delphi
|
|||
---|---|---|---|
#18+
Если мне это одному надо, то, наверное, да, мне быстрее. Я ж об опчестве пекусь Всем, кто использует UUID, хоть "для себя", хоть для совместимости, пусть, с той же 1С, может понадобиться поискать запись по GUID. Сейчас он будет какими-то средствами доставать первичный ключ и по нему уже находить записи. А так - отсортировал колонку по UUID (собственно, с чего у меня и начались "разборки"), промотал до нужной записи. Сейчас это либо невозможно, либо надо быстренько в уме переставить первые четыре байта и, вычислив их, (далее - см. выше) Хотя, нет, так нет. Я же спрашивал, есть или нет. Ответ понятен. ПС. Я уже для себя придумал, что в отладке буду показывать два GUID'а, один "правильный", от MS, и второй - FB'довский. Но, таблиц много, форм, где его надо видеть (в нескольких таблицах свои ГУИДы, например, номенклатура, документы, поставщики...) тоже много, везде городить... Придется... В 1С-ке можно взять только GUID (для связи), по нему надо найти запись в таблице визуально, промоткой, чтобы определиться где и что искать. Или я такой один? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.10.2016, 18:55 |
|
Отображение GUID в IBExpert и Delphi
|
|||
---|---|---|---|
#18+
ivklmА так - отсортировал колонку по UUID (собственно, с чего у меня и начались "разборки"), промотал до нужной записи. Сейчас сортировка работает автоматом только потому, что порядок байт в отображении соответствует порядку байт в физическом представлении как внутри эксперта, так и на сервере. Можно и задом наперед отобразить, только про сортировку тогда можно будет забыть. Я бы попробовал свою SP написать, конвертирующую FB-uuid в MS-uuid. Или UDF, если SP по скорости не устроит. Тогда "правильный" UUID можно будет получать прямо от сервера, и сортировка/поиск работать будут как положено. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2016, 04:02 |
|
Отображение GUID в IBExpert и Delphi
|
|||
---|---|---|---|
#18+
Мне кажется, что делать что-то дополнительно, кроме "нативных" функций, встроенных в ОС и сервер БД, не целесообразно. Всё, что касается сохранения UUID в БД и получения его из БД, работает правильно. В HEX виде оба представления, что в базе, что в программе - идентичны. Проблема заключается в функциях работы с UUID, встроенных в сервер, как то, UUID_TO_CHAR() и CHAR_TO_UUID(). Относительно друг друга они совместимы, но результат их работы не совпадает с результатом функций Delphi GUIDToString() и StringToGUID(), которые, собственно, являются оберткой вокруг функций Windows API, а точнее, функций из библиотеки 'ole32.dll'. Поскольку это так, то какая-либо конвертация данных при сохранении/получении данных и не нужна и вредна, так как будет запутывать пользователя. Единственное, что было бы целесообразно сделать, так это отображение в таблице "правильных" и "встроенных" UUID, но да, поскольку сортировка идет в БД, а не в таблице по текстовому представлению, то о сортировке придется забыть, и цель не будет достигнута. Я, почему-то, думал, что когда я щелкаю по заголовку таблицы, то сортировка идет не на стороне сервера, а на стороне клиента. Если это не так, то вопрос закрыт. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2016, 08:50 |
|
Отображение GUID в IBExpert и Delphi
|
|||
---|---|---|---|
#18+
Еще одна проблема вырисовывается из возможности "скопировать" записи в буфер обмена. Если таким образом сформировать список UUID для передачи другому пользователю, то теряется однозначность интерпретации UUID и GUID, что неминуемо приведет к ошибкам и конфликтам при обмене данными. Вообще-то, странно, что нет однозначности в преобразовании UUID в строку. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2016, 08:59 |
|
Отображение GUID в IBExpert и Delphi
|
|||
---|---|---|---|
#18+
Вот еще от Microsoft версия преобразования GUID в HEX представление. How To Convert a String Formatted GUID to a Hexadecimal String Form For Use When Querying the Active Directory Прим. Обратное преобразование не представлено, но можно вынуть из этого "алгоритма" ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2016, 09:35 |
|
Отображение GUID в IBExpert и Delphi
|
|||
---|---|---|---|
#18+
ivklmЯ, почему-то, думал, что когда я щелкаю по заголовку таблицы, то сортировка идет не на стороне сервера, а на стороне клиента. Да, на стороне клиента. Только в этом случае сортируются там обычные строки в потрохах датасета, который вообще ничего ни про какие UUID'ы не знает. А то, что виртуальное представление этих строк, которое ты видишь в гриде, визуально отсортировано правильно - так это как раз только потому, что порядок байт в этом представлении соответствует порядку байт в строке, соответствующей конкретному UUID'у. Короче, я этим вопросом заниматься не вижу особого смысла. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2016, 09:51 |
|
Отображение GUID в IBExpert и Delphi
|
|||
---|---|---|---|
#18+
Да, согласен. Просто, всем, кто прочитает эту тему, станет ясно, что нельзя использовать строковое представление GUID, как однозначное и везде одинаковое. Одинаково только его HEX представление. И нельзя использовать передачу строкового GUID для передачи в качестве поля связи для однозначной идентификации записи. Покопался тут в представлении UUID (HEX-представления поля в БД) в GUID, так они еще и тетрады переставляют, видимо, чтобы никакие шпиёны не догадались. Важна только однозначность преобразования (из строки)<-->(в строку) в конкретной реализации. В этом смысле UUID_TO_STR и обратно, даже, логичнее, чем "стандарт от Microsoft", поскольку это просто последовательное представление байтов с разбиением на блоки с помощью дефиса (-). ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2016, 11:37 |
|
|
start [/forum/topic.php?fid=42&fpage=20&tid=1599192]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
31ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
45ms |
get tp. blocked users: |
2ms |
others: | 265ms |
total: | 388ms |
0 / 0 |