LO-7.2

[Kadet]

"Никогда такого не было и вот,.. опять!". (В.С.Черномырдин)

"Неожиданно", после установки новой LO-7.2 все мои демо-базы со встроенной БД перестали работать.
В некоторых пока даже приблизиться не могу к моменту ошибки. Просто крах и всё при начале работы. Вернее база загружается, но у меня все они сразу начинают загружать рабочие формы и формировать их заполнение.

Во второй получил следующую проблему:

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


[b]Невозможно определить содержимое поля со списком или поля списка.[/b]

firebird_sdbc error:
*Unrecognized C++ exception
caused by
'SELECT DISTINCT "ТОВАР"."Стенка", MAX( "РАЗМЕРЫ"."ID" ) FROM "ГРУПП", "РАЗМЕРЫ", "СИМВОЛЫ", "ТОВАР" WHERE "ГРУПП"."Кр" = "РАЗМЕРЫ"."Кр" AND "ГРУПП"."ID_sim" = "СИМВОЛЫ"."ID" AND "ТОВАР"."ID_razmer" = "РАЗМЕРЫ"."ID" AND "РАЗМЕРЫ"."Кр" > 2 AND "ТОВАР"."Остаток" > 0 GROUP BY "ТОВАР"."Стенка", "РАЗМЕРЫ"."R3" ORDER BY "РАЗМЕРЫ"."R3" ASC'

Этот запрос прицеплен к открывающейся форме, т.е. - "Свойства формы -> Данные -> Запрос"... В общем, это запрос самой формы и ошибка выдаётся при выполнении команды oForm.load.
При попытках выполнить подобные действия с другими формами - получаем то же самое, только с другими запросами.
В этой базе автоматически загружается "пустая" форма, без запросов, а запросы подвязываются при открытии нужного вложения, т.е. - субформы. Такой фокус для ускорения открытия форм.

В последующих же базах дело обстоит ещё хуже.
Во-первых, загрузка самих баз стала в десятки раз дольше. Не могу объяснить причины. Вроде бы все технологии загрузки до открытия рабочей формы у меня идентичны, но... почему-то во-второй всё открывается быстро, а в 3-й, 4-й - дикая задержка.
И в последующих базах рабочие формы созданы с уже жёстко привязанными запросами и крах происходит уже при самой загрузке, и поймать момент ошибки пока не удаётся.

При этом, нужно признать, что база с внешней БД - работает прекрасно, и никаких фандиперсов не наблюдается.

Ещё толком не разобрался в чём собака порылась, но полагаю, что в этой версии внесены какие-то изменения в доступы к встроенной БД или в обработку запросов во встроенной БД... А возможно, проблема в обработке кириллицы, опять же - во встроенной БД...

В общем, Бог его знает, но мои демки, созданные на встроенных БД, перестали работать. "Неожиданно".

[Kadet]

А вот, эти обещанные улучшения, были бы весьма кстати в моей работе:

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

Представление

   Повышена скорость рисования больших изображений tdf # 138068 tdf # 140797 . (Любош Лужак, Collabora)

   Повышена скорость рендеринга текста при использовании резервного шрифта. Core commit 7439cabc . (Любош Лужак, Collabora)

   Улучшена интерактивность медленных операций рисования с повторяющимся пользовательским вводом. Ядро commit d3b498cc . (Любош Лужак, Collabora)

   Различные улучшения скорости рисования при использовании серверной части рисования на основе Skia. (Любош Лужак, Collabora)

   Увеличьте скорость загрузки документов с помощью zlib optimized crc32 core commit 85ed3a47 . (Любош Лужак, Collabora)

   Повышена скорость свопинга и потребление памяти графикой (Томаж Вайнгерл, Collabora)


Но,.. "что-то пошло не так"...

[eeigor]

Самое интересное, что в Base изменения, согласно обзору, не вносились.
https://wiki.documentfoundation.org/ReleaseNotes/7.2#Base

[Kadet]

Думаю, потянули какие-то изменения ядра. Они там много всякого "наковыряли".

Причём, забыл упомянуть, эта ошибка у меня проявилась и в Win-10(х64) и в Win-7(х86) одинаково.

[Kadet]

Отключил запросы, привязанные к формам... и О ЧЮДО!!! Заработало. Всё загружается, макросы выполняются, обращения к базе данных не сбоят, и запросы из макросов тоже без проблем.

Значит проблема возникает только с запросами, привязанными к формам.

Что-то мне подсказывает, что что-то нарушилось после "улучшения" форм в LO, опасанных в сопроводиловке.

P.S.: однако, почему-то эта проблема не проявляется при работе с внешней БД. Хотя там у меня каждая форма с запросами, но сбоев нет. Полагаю, что собака порылась в доступе к БД. Во внешней БД доступ к БД получается при запуске самой БД, т.е. - автоматически идёт запрос паролей и т.п. А во встроенной такой аутентификации нет, да она и не предусмотрена.
Запросы из макросов всегда сопровождаются открытием доступа к БД, потом запрос, потом закрытие доступа. Поэтому там всё работает. А вот в формах такая процедура не предусмотрена. Как бы раньше доступ получался автоматически, ведь БД то встроенная.
А сейчас... что-то пошло не так. Либо нужно искать как же открывать доступ к БД до или в процессе открытия форм.

[economist]

А "рояль" из галочек св-в подключения к FireBird не поменялся? Обновления LO Base редко, но сопровождались их самопроизвольным выкл/вкылом. 

[Kadet]

Дело в том, что Base со встроенной БД этот рояль скрыт, не доступен.

Опять таки, сейчас наткнулся на уже древнюю проблему со встроенной БД. Однако, раньше она проявлялась только при использовании команды SQL - list, теперь же она вылезла и в других вариантах.

В общем, так. При получении списка строковых значений путём простого запроса, допустим такого:

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

oSql = "SELECT list(""Марка"",'"";""') FROM ""МАРКА"""
Встроенная БД выдаёт список значений которые после самих данных заполнены какими-то невидимыми символами. Это не пробелы, а какие-то другие символы (пробовал их удалять путём replace, не получилось). Полагаю, что количество этих символов добивает поле до полной размерности, т.е. - если закладываешь поле длинной - varchar(32), но при этом заносишь в него строку - "Текст", то вся остальная пустота после "Текст" до самой полноты поля (32 символов) забивается некими пустыми символами. Получается примерно так: "Текст                            ".

При этом, если получать конкретные значения поля по одиночке, допустим так:

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

oSql = "SELECT ""Марка"" FROM ""МАРКА"""
Этого эффекта не наблюдалось. Поэтому раньше обходил эту проблему макросом, который методом перебора выбирал все полученные значения запроса и загонял их в массив.

Теперь же, в LO7.2 эта проблема выскочила при любом виде получения строковых значений запросов.

Нужно добавить, что при работе с внешними БД таких проблем не наблюдается. И при list и по одиночке все строковые значения получаются без проблем и всяких ненужных дополнений.

[Kadet]

Очень жаль, что после очередного обновления LO весьма часто приходится вносить изменения в свои программы.

[mikekaganski]

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

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

[economist]

Действительно, встроенный движок FB не имеет свойств (даже HSQLDB их имел).

Могу предложить перейти на SQLite:

1) установка и настройка JDBC-драйвера не нужны, просто скопировали 2 файла и переподключились

2) ODBC-драйвер и Python-доступ (С-либа sqlite3) - быстрый (1,5X) и очень быстрый (5X) по сравнению с JDBC

3) не нужны тонны кавычек, сравните
oSql = "SELECT ""Марка"" FROM ""МАРКА"""   ' FB/HSQLDB
oSql = "SELECT Марка FROM МАРКА"             ' SQLite

4) не нужна явная группировка для агрегатов (тут на любителя)

5) прямой доступ по сети для 3-5 пользователей с уровнем комфорта "как в MS Access". Если юзеров больше - сразу смотрите в сторону PostgreSQL или MySQL (штатные коннекторы работают отлично)

6) вкупе с тем что SQLite самая быстрая встраиваемая БД - вернуть большие таблицы в Calc методом doImport() - эффективнее всего именно так. А вычисления можно cделать перед возвратом - в Pandas/Numpy (быстро, надежно)

Мои приложения с SQLite на OO3-4 и LO 4-5-6-7 сохранили прямую и обратную совместимость, ломалось пару раз за 15 лет, скорее всего по причине личной криворукости. Это системы упр. учета, показать не могу, но во многом схожи с тем что вы делали для метизов.

[Kadet]

economist, Вы, наверное, не заметили, но я часто упоминаю, что основные рабочие мои базы давно работают на внешней БД FireBird... Даже когда-то тему писал с описанием проблем подключения. И меня во внешнем БД всё устраивает, LO 7.2 с внешними БД работает безупречно (по крайней мере я пока не нашёл никаких косяков)...

Однако, параллельно мне нужны и встроенные БД. Я их использую в демках моих программ. Ведь потенциальному пользователю нужно показать свою работу как можно упрощая процедуру установки. А подключение любой внешней БД, будь-то FB или SQLlife - это целое дело.
Как-то так.

Сейчас снова столкнулся с необходимостью подключать запросы к формам. Без них поля со списками, списки которых тоже формируются запросами, просто пусты.
Багзиле писать, что ли?! (Опять заругают, закритикуют... всё сделал не так и не эдак)...

[Kadet]

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

Ссылку с описанием КАК пришлите, пожалуйста. Трудно выискивать по своим постам такую "древность".
А-то забыл как это делается.

[mikekaganski]

https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice

[Kadet]

5) прямой доступ по сети для 3-5 пользователей

У FireBird количество одновременных пользователей формально ограничивают числом - 100. В нашем предприятии человек 15 пользуют базу одновременно... не считаю внешних, удалённых подключений.

[Kadet]

https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice

Не,... я не ту просил. Когда-то мне присылали описание как качать бинарники и делать багрепы. Я именно его просил.