LO-7.2

[economist]

Приложение, использующее RDBMS может хранить все настройки в отдельной таблице БД. Или в константах модуля в одном месте. Или в текстовом INI-файле на диске. 

[Kadet]

М-да. Заморочка со свойствами в Base.
Конечно, можно найти и более хитрые способы, но, снова, я искал более лёгких путей, коих получается нету.

Вышел из положения простыми манипуляциями с титлами. Небольшая проблема в том, что, опять таки, переменные из внутри документа не передаются в глобал, а версию я достаю (храню в минимакросе), как и начинаю работать, во внутренней библиотеке, а потом перехожу во глобальную... Так вот там не желательно хранить ни версии ни пароли.
Поэтому во внутренней библиотеке в тилу записываю номер версии (по-автомату титлы Base в этой версии LO, почему-то, пусты, потом лишь в формах они появляются). А во внешней библиотеке читаю эти титлы и меняю на "родные" - название документа.
Конечно, можно просто передать как параметр, но этот параметр не в первом глобальном макросе востребован... и по цепочке передавать от макроса к макросу не хочется.

Почему-то, в LO Base очень часто приходится прибегать ко всякого рода хитростям и изворотам.

[economist]

Kadet - мне кажется вы сильно (эволюционно) переусложнили свое решение. Вот пара мыслей "теоретика" по паролям для защиты LO-приложений от копирования у клиентов и где их хранить. Нам, LO-шникам, в чем-то повезло, но тема слабо документирована, так что везение оказалось ложным. Везет в том что Модуль на почти любом языке Basic/Python/С++/Java/JS(?), даже запароленный - можно вручную/полуавтоматом встроить в сам ODF-документ, или разместить модуль в LAN, и даже WAN, на сайте. Но вот делать так иностранные программисты не советуют, потому что реверс-инженеру с расценкой 300 Евро/час, владеющему отладчиком - несложно за часы понять что и где и промэпить все случаи вызова и ответа модуля, написать рабочий патч, зарулив на него все check-вызовы.

Для Excel написано много подобного прикладного софта (складских "помогает" - в тысячи раз больше, чем для LO). И ведь VBA-проекты в MS Excel - родными методами не защитишь, всё до сих пор (с 1995 г.) вскрывается заменой одной буквы на другую в любом редакторе (типа FarManager), за минуту. Для LO подобных простых гайдов по снятию пароля я не находил, возможно их и нет. Но...

Программисты с зарубежных форумов неустанно советуют пароли хранить не в документе, не в модулях, не глобальных константах, не возиться с их "передачей" в процедуры разных модулей, сталкиваясь с непонятками вроде ваших, а хранить пароли в виде хешей (отпечатков пароля) в отдельных текстовых файлах, куда они бесхитростно запишутся в несколько строк кода, например, на Python (только потому что для него море примеров, а для Basic - единичные на старых OO-форумах).

Для Python есть хороший модуль PyArmor с кучей однострочных примеров, который по железу (номер диска/тома/раздела, ID CPU/MB, внешнему IP-адресу итд - т.е. тут полный фарш готовых привязок к "железу", включая триальные) сделает вам готовый MachineID. Да и готовых отдельных либ для чтения/генерации MachineID - хватает, их десятки (Basic явно проигрывает, тут без внешнего "Scripting.FileSystemObject" даже серийный номер тома C:\D: не считаешь, да и он - "проживет" лишь до следующей переустановки винды и его, как и EMEI, можно подделывать утилитами Руссиновича).

Введенный пароль, по сути - "соль", не зная, может вводить даже сам клиент, например свой ИНН), во время установки или первого запуска (хотя чаще вы выдаете/присылаете/позволяете скачать с GoogleDrive хеш-файл по MachineID клиента). Одним словом, ваш макрос запишет хэш пароля/ID машины и хеш от соли на диск в txt-файл. Суть хеширования - невозможно по хешу вычислить пароль, поэтому хеш не нужно прятать, пусть лежит явно.

А дальше все сразу становится просто: ваши макросы в приложении могут кое-где и лишь иногда сравнивать хэш с хэшем во внешнем TXT-файле, читать которые Basic умеет быстро и бесконфликтно (в pyarmor для этого написаны замудреные, но быстрые функции, которые даже прятать/обфусцировать не надо). Таким образом на другом PC - программа запустится, но работать будет не во всём или не всегда. Именно такая ненавязчивая и незаметная поначалу защита, вкупе с невысокой ценой на доплицензии и его регулярным улучшением (с поддержкой) в новых релизах, являются, кмк, лучшей защитой от пиратства.

Учитывая среднестат. "воронку продаж в деловом ПО в РФ" 50:1 (из 50 ЮЛ/ИП которые скачали вашу демку - купит ~1) - можно послушать совета больших программистов и сделать отдельную демо-версию или даже Lite-версию по принципу donationware, на другом "встроенном" движке (я опять про SQLite - там все запросы незакавыченные, и диалект SQL92 в полный рост и перевод не должен быть сложным). Лично для меня эта ветка стала хорошим сигналом не использовать FB Embed движок в Base ни для каких целей, уж больно много странностей вылазит по факту.

[Kadet]

economist, спасибо за информацию!
Пока вопрос защиты такого уровня передо мною не стоит. К тому же, мои заказчики чаще не слишком "спецы" в программировании и т.п. А если у них и есть спецы способные расковыривать защиту, то вряд ли они обратились бы ко мне.
Поэтому считаю, что на данном этапе существующая защита вполне достаточная.

Однако, после того как я закончу основную свою "горячку" по созданию последней программу по заказу, то планирую обратиться к этой теме и детально разобраться в ней.

Однако, спасибо!

[mikekaganski]

Можно попросить Вас проверить работу ваших исправлений на моей дополненной демке (# 148) и в моей базе (Cyanopica4) на запросах:

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

SELECT "Заказчик", "ID"  FROM "ЗАКАЗЧИКИ" GROUP BY "Заказчик", "ID"  ORDER BY UPPER("Заказчик") ASC

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

SELECT DISTINCT "Заказчик", "ID"  FROM "ЗАКАЗЧИКИ" ORDER BY UPPER("Заказчик") ASC

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

SELECT list("Размер",';') FROM (SELECT DISTINCT "Размер" FROM "РАЗМЕРЫ" WHERE "Кр">0 ORDER BY "Кр" ASC, "R1" ASC, "R2" ASC, "R3" ASC)

После исправления tdf#144340 первый и второй работают в Cyanopica4 без нареканий, а третий виснет.

Но что Вы подразумевали под "на моей дополненной демке"? Там (во встроенной базе) только одна таблица "Months".

[Kadet]

Но что Вы подразумевали под "на моей дополненной демке"? Там (во встроенной базе) только одна таблица "Months".

Я наверное, не правильно выразился или Вы меня не правильно поняли.
Эти запросы я просил попробовать в Cyanopica4. Естественно в демке таких таблиц нет.

А демку я вообще просил проверить с вашим плагином. В посте # 148 помимо картинок в самом верху леит zip-архив, в котором лежать изменённая демка со встроенной и демка с выделенной базой. Вот встроенную я и просил проверить с Вашим плагином.

[Kadet]

Лично для меня эта ветка стала хорошим сигналом не использовать FB Embed движок в Base ни для каких целей, уж больно много странностей вылазит по факту.

Мне кажется, что Вы сравниваете не сравнимые вещи, и на этом основании делаете неправильные выводы по поводу FB.
В этой ветке изначально было сказано, что проблема в новой версии LO возникла ТОЛЬКО во встроенной БД. А Вы сравниваете встроенную БД с выделенной SQLite, которая по-умолчанию выделенная и никак не может быть встроенной.
А с выделенной и с FB - никаких проблем нет. Великолепно работает. О чём неоднократно было заявлено.

Поэтому, не стоит грешить на FB. Тут проблемы другого характера - взаимоотношения между встроенными строктурами Base косячат.

[mikekaganski]

После исправления tdf#144340 первый и второй работают в Cyanopica4 без нареканий, а третий виснет.

На самом деле третий тоже прекрасно отрабатывает, а зависает при попытке показать его в таблице результатов запроса. Запрос возвращает BLOB, в котором больше 50000 байт, большинство из которых нулевые байты ... баг, наверное, но если честно, я даже не знаю, как оно отработает на неотладочной версии - может быть, вполне шустро. А у меня просто терпения не хватает дождаться.

EDIT:
Проверил на 7.1.0.4 (релизной, не отладочной). Третий запрос тоже надолго зависает при показе. Так что по итогу - в исправленной версии всё работает теперь не хуже, как в 7.1.

[Kadet]

На самом деле третий тоже прекрасно отрабатывает

Третий запрос, да... Возможно я с ним погорячился. Он делает выборку из таблицы в более 500 записей, и всё это должен записать в виде одной строки. Хотя... что такое 500 записей по 5-11 символов? Максимум 5000 символов... плюс разделители - пусть 500шт. - 5500 символов... Чай не "Война и мир", таки... не так уж и много.
Но, видимо, сляпывание из отдельных записей одной строки сама по себе процедура не быстрая.

[mikekaganski]

На самом деле третий тоже прекрасно отрабатывает

Третий запрос, да... Возможно я с ним погорячился.

Это был tdf#120129. Исправлено. Проблема, как я уже писал, была не в запросе, а в отрисовке результата, который содержал нулевые байты, ставящие в тупик отрисовку текста.

[economist]

сравниваете встроенную БД с выделенной SQLite, которая по-умолчанию выделенная и никак не может быть встроенной.

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

При этом скорость, простота и удобство без-серверной, без-типовой SQLite, имхо, намного выше чем у HSQLDB/FireBird_Embed. Опциональное использование встроенного Python для больших транзакций - делает SQLite почти "серверной" (задействуется WAL-журналирование, которое убирает конфликат записи вида "четверо читают или один пишет"). В итоге SQLite по скорости легко "делает" MS Access, в поисках замены которого сюда на Форум частенько заходят. Для демок с одной кнопкой  "Скачать и Запустить" - самое то. Ну а мы такое используем в "проде", на уровне отделов. Скорости хватает, а отсутствие необходимости регить юзеров, конфигить сервер с MySQL/PostgreSQL/FireBird_Server и общаться с IT-шниками - приводит к тому что некоторые проекты "автоматизации снизу", целиком на базе СПО, сделанные без спросу, - выстреливают быстро, с большим профитом, без затрат и "откатов". Для значительной (имхо, это 70%) части предприятий наш LibreOffice с "плюшками" - это единственный способ что-то реально автоматизировать у себя из рутины.

Ежли это "самовозгорание" не происходит - через год-два придет беда "эффективный менеджер", притащит "своего" консалтера+вендора, они вместе запудрят мозги владельцам и фирма, потратив пару лямов - получит "еще одну непонятно кому нужную программу" (в дополнение к 1С/CRM/EDM/Excel/etc).

[mikekaganski]

В общем, вот синопсис багов, затронутых в теме.

1. Связанные с Firebird.

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

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

oSql = "SELECT list(""Марка"",'"";""') FROM ""МАРКА"""
Встроенная БД выдаёт список значений которые после самих данных заполнены какими-то невидимыми символами.

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

Это был баг обработки CLOB (текстовых BLOB) в драйвере SDBC Firebird - tdf#120129. Исправлен сегодня.
Только теперь можно сказать, что

А list, оказывается, стал нормально работать

Область поисков сужается.
Простейшие запросы:

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

SELECT "Размер" FROM "РАЗМЕРЫ"

И он же с группировкой:

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

SELECT "Размер" FROM "РАЗМЕРЫ" GROUP BY "РАЗМЕРЫ"."Размер"

Дают следующие результаты. (вложения).

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

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

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

Я ошибался в том, что эти вещи связаны; это был tdf#144340, связанный с обновлением Firebird до релиза 3.0.7 в ЛО 7.2; при этом свойства конфигуратора FB, в связке с хаком ЛО для его интеграции, привели к неправильному определению размера типа long long под Windows, и как следствие - разрушению данных в памяти при сортировке в Firebird. Исправлено в понедельник.

В процессе работы с ним я написал tdf#144230 и "исправил" его - но по факту то исправление оказалось паллиативом, и в свете вышеуказанного фикса уже не актуально. Однако убирать его не буду, оно не мешает.

Тестируя базу из ответа 45 в 7.2.1.1 и в мастере под Win10, я вижу, во-первых, зависание намертво - связанное, по-видимому, с багом в Firebird (жду ответа на комментарий здесь)

Это был tdf#144172, связанный с возможностью запуска нескольких встроенных движков FB, настроенных на использование разных расположений служебных директорий, одновременно на системе - например, из нескольких параллельно установленных ЛО, или из ЛО + из ванильного FB. Присутствовал изначально; виден только тогда, когда пытаешься использовать такие движки одновременно. Это была моя локальная проблема, исправленная неделю назад.

Дополнительно внесены некоторые внутренние изменения в код интеграции FB, которые не исправляют никаких ошибок, а, например, помогают в отладке, устраняют ненужные повторные чтения одних и тех же данных или используют более эффективные структуры данных.

И ещё работа над этими проблемами инициировала некоторые (хоть и небольшие) изменения в самом Firebird: раз, два (в работе).

2. Не связанные с Firebird

Я вот что заметил: если из Calc запустить макрос, а в другом модуле этой же библиотеки (пользовательской) будет ошибка, то в LibreOffice 7.2.0.3 виснет офис, а в LibreOffice 5.0.6 сообщает об ошибке без зависаний.

Это был tdf#144183 (регрессия в 7.2), исправлен 31 августа.

Резюмирую: оччччень продуктивная тема получилась. Спасибо Kadet!

[Kadet]

Спасибо за исправления и помощь!

Надеюсь всё это войдёт в ближайшую версию LO.

[mikekaganski]

Надеюсь всё это войдёт в ближайшую версию LO.

Нет, не всё в ближайшую. ЕМНИП что-то только в 7.2.2.