LO-7.2

[mikekaganski]

Область поисков сужается.

Найс! Воспроизводится на Вашей Cyanopica4. Можно попробовать найти проблему.

Ощущение, что это - следствие первоначального

Встроенная БД выдаёт список значений которые после самих данных заполнены какими-то невидимыми символами.

Явный баг - доступ к неинициализированной памяти или unchecked bounds - обязательно нужен багрепорт.

[Kadet]

Ощущение, что это - следствие первоначального

Я бы сказал - усугубление.
Раньше не проявлялось, а вот первое, для внутренней БД, было ещё в 7.1, на оператор LIST в запросах. В 7.2 "расширило зону охвата". Ранее не проверял.

[Kadet]

В большинстве диалектов SQL крайне не рекомендуется (или запрещено) применять не латинские буквы для именования объектов баз данных: таблиц, представлений (View), полей, индексов, триггеров и т.д. Лучше неукоснительно следовать этому.

FB был всегда толерантным к этому. Проблемы возникли лишь при экспорте БД из старой HSQL (или как её там было) в FB. Других проблем не было.
К тому же, судя по исследованиям проблемы возникают в самих полях, а не в их названиях.
К тому же, в других запросах с несколькими таблицами, с этими же полями - никаких проблем не наблюдается.

[Kadet]

Ещё немного интересных примеров.

Ширина столбцов выставлена автоматически двойным кликом, значит там не пустота, а невидимые символы. В некоторых случаях они заканчиваются какими-то кракозябрами.

Вот запросы для проверки.

Код Выделить Развернуть

SELECT "Поставщик" FROM "ПОСТАВЩИКИ"
SELECT "Поставщик" FROM "ПОСТАВЩИКИ" GROUP BY "ПОСТАВЩИКИ"."Поставщик"

SELECT "Группа", "ID" FROM "ГРУППЫ"
SELECT "Группа", "ID" FROM "ГРУППЫ" GROUP BY "ГРУППЫ"."Группа", "ГРУППЫ"."ID"

[mikekaganski]

Да там непонятки какие-то с размером данных. Varchar передаётся в структуре, у которой есть общий размер и указатель на данные, которые в свою очередь начинаются двумя байтами - длиной строки, а затем сама строка. И вот запрос из ответа 131 выдаёт записи, которые имеют общий размер 402 байта, и указатель на строку, начинающуюся двумя 255 (т. е. длина строки как бы 65535 байт). После этого идут, например, байты "0.8", затем 397 пробелов, а потом мусор за пределами записи. И этот мусор попадает в строку общей длиной 65535 байтов, пытается конвертироваться из utf-8 в utf-16, и потом вы видите то, что вы видите. При этом оно тормозит и крашится.

Причём есть простой способ убрать тормоза: при чтении записи брать не число, идущее перед строкой, а минимум из этого числа и размера данных за вычетом 2 байт. Но во-первых, почему длина строки врёт? И во-вторых, зачем пробелы?

[Kadet]

Но во-первых, почему длина строки врёт? И во-вторых, зачем пробелы?

Вот с этим полностью согласен. Тем более - лишние надстройки - это тормоза (очень заметно при удалённом доступе к базе).
К тому же, ведь это проявляется лишь с встроенной БД, которая подразумевает вынесения во вне в беседующем. И выстраивать запросы, усложнять и надстраивать для демки (подразумевая, что их потом придётся переделывать)... не резонно. Ведь эти же макросы в детальнейшем должны работать и в выделенке, где таких проблем не наблюдается.
Не резонно.

[Kadet]

Вот ещё нашёл лазейку. Если убрать большое строковое поле из группировки, то работает нормально.

Висяк:

Код Выделить Развернуть

SELECT "Размер", "ID" FROM "РАЗМЕРЫ" WHERE "Кр">2 AND "Кр"<19 GROUP BY "Размер", "ID", "R1", "R2", "R3", "Кр" ORDER BY "Кр" ASC, "R1" ASC, "R2" ASC, "R3" ASC

Нормально:

Код Выделить Развернуть

SELECT MAX("Размер"), "ID" FROM "РАЗМЕРЫ" WHERE "Кр">2 AND "Кр"<19 GROUP BY "ID", "R1", "R2", "R3", "Кр" ORDER BY "Кр" ASC, "R1" ASC, "R2" ASC, "R3" ASC

Это ещё пол беды. Выяснилось, что мои надежды на то, что эти проблемы проявляются только в формах и полях-списках, не оправдались. Такая же проблема проявляется и в исполняемых запросах, при формировании таблиц, отчётов и пр. А все базы построены именно на тих. Это большая проблема... ОЧЕНЬ БОЛЬШАЯ проблема... для меня, по-крайней мере.

[mikekaganski]

Скорее всего, дополнение пробелами при использовании группировки - нормально, и является частью стандарта. Там есть два режима сравнения строк (collation), и вероятно, для сортировки по умолчанию используется режим PAD SPACE. Ведь для группировки нужно сравнивать значения. Но вопрос - почему различие в поведении с внешней базой?

С другой стороны, я не увидел проблемы в маленькой базе, созданной с нуля. Что-то особое в таблице RDB$COLLATIONS, что объяснило бы отличия?

[Kadet]

Логически выстраивается направление проблемы - всё так или иначе связано с групповыми операциями со строковыми полями:
DISTINCT, GROUP BY... LIST, скорее всего, тоже работает по этому же алгоритму.
Нужно будет проверить другие групповые операции SQL.

[Kadet]

Одновременно об одном и том же.

[Kadet]

С другой стороны, я не увидел проблемы в маленькой базе, созданной с нуля. Что-то особое в таблице RDB$COLLATIONS, что объяснило бы отличия?

Некоторые отличия есть. Во-первых там поля по Varchar(32) - маленькие. Я прогнал запросы по большинству своих таблиц и заметил, что проблема наиболее ярко проявляется в больших полях. В частности самое проблемное поле - "Заказчик" - Varchar(255).
Во-вторых, как мне показалось, количество полей в самих таблицах тоже, кажется, влияет. В маленькой таблица малышка - 12 записей. А в базе тысячи.

Попробовать увеличить размеры полей в маленькой демке?!

[Kadet]

Проверил. Проявляется (видно длина строки августа выделена, с невидимыми символами). Только не тормозит.
Увеличил размеры полей до 255.

И ещё один интересный казус заметил. Если при всех тех же, добавить и английское поле, то всё работает нормально и ничего не проявляется.

[mikekaganski]

tdf#144230

[Kadet]

Сделал небольшую демку с вынесенной БД. Только для её запуска нужно пройти заморочки по установке и настройке Firebird-Server и ODBC Firebird Driver. Как устанавливать описал в ReadMy.

Так же изменил демку из #17. Внедрил группировки в запросы, добавил запросы на руссифицированные поля и всё стало проявляться. Даже в англоязычных полях. Причём даже размеры полей не увеличивал, оставил - varchar(32), и всё равно проявляется.
Т.е., вывод - кириллица и размеры полей - ни при чём. Проблемы с групповыми операциями в целом.

А при выделенке - действительно ничего не проявляется. Всё работает чётко.

MyDB - БД встроена в файл .odb
MyDBvn - БД вынесена на сервер.
(всё во вложении - MyDBvn.zip).

Запускаем форму Months и нажимаем на кнопки.
На кнопках написаны тексты запросов, которые выполняются по ним.

Чтобы понять реальные размеры строковых результатов можно сделать следующее.
В MyDB в форме Months нажмите на любую кнопку с запросом.
Появится диалоговое окно, со списком результата запроса.
Нажать на диалоговое окно мышей (в любом месте кроме ОК) и Ctrl+A (лат) - "выделить всё".
Весь текст диалогового окна выделится и будет видны границы строковых результатов.
Можно повторить и в MyDBvn, но там и так всё видно.

[Kadet]

А list, оказывается, стал нормально работать (судя по демке).
Давно мечтал об этом. Нужно будет все подобные запросы, коих у меня тьма, переключить на list. Он быстрей работает, чем по одной выбирать и For-ом в массив загонять.