Функции в запросах

Автор st.inna, 24 мая 2023, 14:55

0 Пользователи и 1 гость просматривают эту тему.

st.inna

Всем здравствуйте!

Есть задача "переписать" запросы, разработанные в MS Access, чтобы они работали в LO BASE.
Столкнулась с тем, что какую функцию не возьму, которая работает в Access, LibreOffice ее не знает.
Например, простая функция MONTH(CURRENT_DATE) в LO работает только в таком виде: EXTRACT(MONTH FROM CURRENT_DATE). Сейчас на дворе май, поэтому возвращает значение '5'. Теперь мне нужно эту пятерку перевести в название месяца, но функция MONTHNAME не работает ни так: MONTHNAME(CURRENT_DATE), ни так MONTHNAME(EXTRACT(MONTH FROM CURRENT_DATE)).

Не работает также функция MID для обрезки части строки внутри нее.

И это еще только то, с чем я столкнулась...

Какой стандарт SQL для написания запросов? Именно запросов на закладке "Запросы", не в макросах.

Есть ли какое-то соответствие функций в Access и BASE? Например, NZ в Access - это COALESCE.

Можно ссылочку на умную статью...

СПАСИБО

economist

Вы не упомянули используемый движок БД (см. левый нижний угол окна BASE) и формат файла БД. Некоторые функции MS Access реализованы как UDF в штатной библиотеке Access2Base, другие можно переписать на BASIC или найти эквиваленты в других движках:
MID/LEFT/RIGHT -> SUBSTR
5=Май -> CASE WHEN 5 THEN 'Май' WHEN 6 THEN 'Июнь' ... END
итд. Решения есть, статей - нет. Видимо каждый прошедший этот путь так устает, что не до статей.   

Вот еще что важно: не сесть сразу на "дохлую лошадь". Движок HSQLDB - устарел и будет удивлять тем что даже документированные функции работать не так как написано. И наоборот, движок SQLite будет работать быстрее остальных, а средствами Python легко реализовать регистрацию новой UDF-функции в нем, и ее можно использовать в SQL-запросах как родную. Штатный движок БД по умолчанию FireBird оставляет двоякое впечатление: вроде быстр, есть дока на русском, но урезан, не серверный, аналог Access на нем сходу на запилишь, своеобразный и строгий диалект SQL, не очень умеет линковаться с TXT-файлами итд. Вполне возможно стоит рассмотреть большую троицу: SQLite MySQL PostgreSQL. с которыми грех жаловаться на к-либо ограничения, а опыт работы с ними 100% пригодится где-то еще.     
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

st.inna

И правда, как я забыла написать про движок? :-\
FireBird. И да, на нем сложно создать аналог базы данных, уже ранее разработанной в Access, но я пытаюсь. Почему выбрала FireBird? Потому что при создании БД в BASE было только два варианта - он и HSQLDB, но уже прочитав о том, что он устарел, выбор был сделан в пользу FireBird. Перечисленные Вами SQLite, MySQL, PostgreSQ только как вариант подключения к уже существующей БД. И если я правильно поняла через подключение мы видим только таблицы, а в самом BASE мы делаем только формы, запросы и отчеты. Я вообще не программист, поэтому могу только догадываться, что это так. Как создать сами таблицы в SQLite, MySQL, PostgreSQ я не знаю, поэтому и выбрала FireBird. Конечно, отсутствие возможности работы в нем в многопользовательском режиме для меня большой недостаток, но планировала выходить из него через работу с автономными формами, хотя это не совсем удобно (и пока понятия не имею как) переключаться между различными формами. Любая помощь в этом направлении будет не лишней  :) Мое образование никак не связано с программированием, но род деятельности заставляет разрабатывать небольшие базы данных для автоматизации работы маленькой химической лаборатории (автоматический расчет результаты анализов, учет химических реактивов и т.д.), поэтому изучение данного вопроса для меня, конечно, актуально. Мною очень даже неплохо был освоен Access, SQL под него, но обязательный переход на работу с Astra Linux похоронил все мои знания. Спасибо за любую помощь!

kompilainenn

Цитата: st.inna от 25 мая 2023, 10:21переход на работу с Astra Linux похоронил все мои знания.
Попросите руководство переобучить вас с учетом новых реалий
Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут

economist

SQLite работает без сервера и позволяет комфортно работать 3-5 человекам одновременно с одним файлом *.sqlite3 по сети LAN, по ощущениям - точно так же, с тем же комфортом, как в MS Access с файлом *.mdb или *.accdb. При этом база м.б. большой (гигабайты) с десятками таблиц и миллионами строк. В SQLite есть все кроме шифрования данных и ACL (прав доступа на базе имен/ролей), но обычно хватает файловых прав на базу. 

Если вы знаете SQL - знания не пропадут, т.к. создавать/менять таблицы, индексы итп можно самими SQL-запросами (DDL-командами). Для MySQL и PostgreSQL - да, нужен сервер (процесс, запущенный отдельно). Есть их portable-сборки, запустили на своей же машине и получили готовый "сервер" с ACL.

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

Вы пробовали "подключаться" к *.mdb или *.accdb из LO Base в Astra? Есть как минимум 2 способа (родной и драйвер) плюс должно работать UnixODBC - подключение. Движок у MS Access тоже есть, он называется MS Jet или MS Ace (шатный компонент любой Windows. начиная с XP), возможно есть реализация для линуксов. Ни одной винды в офисе не осталось? Если остались - можно подключиться к ней и работать с базой с клиентских линуксов, хотя бы как временное решение, до окончательного переезда. В сети были успешные истории с виртуальными машинами Win под Lin и движком, хотя по мне это самостоятельное заболевание с немалыми затратами труда.

Автономные формы для БД в OpenOffice|LibreOffice - это просто Writer-файлы *.odt, в которых нарисованы произвольные контролы (списки, флажки, таблички итп), в свойствах которых указаны Таблицы, Поля, Запросы из вашей БД (или SQL-строка запроса, дающая то же самое). Все это работает нормально, иногда падает, имеет небольшие ограничения. Число odt-файлов должно быть равно числу одновременно работающих людей, т.к. одним файлом в режиме для чтения пользоваться не так удобно и местами глючно. SQL внутри контролов вполне может превратить 5 из БД в "мая" в форме/отчете, т.е. это еще один SQL-слой для БД. 

Насчет химлаба и расчетов - специфика глубока и она всегда рождает энтузиастов с прорывными разработками, поищите их in english в Google. Сейчас многие лабы оказались в новой ситуации. Торных путей нет, но многие тропят целину и при должном подходе - поделятся с вами своими наработками.

Также попадались специализированные химические библиотеки для Python (искать на pypi.org, например по запросу chemical symbolic formula calculation). Они умеют считать молярные объемы, знают таблицу Дмитрия Ивановича, плотности всех элементов и почти всех веществ (а также t плав/кип, уд. теплоту сгорания итд), вычисляют химформулы, то есть умеют в символьную химическую арифметику 2H+O = ..., знают все константы и мн. другое. Это может сильно разгрузить SQL от сложных вычислений, благо в LibreOffice Astra - python есть и он легко интегрируется (а сам python кладет данные в БД SQLite и остальные кладет так же быстро, как родные средства). Все 450k+ либ для Python - свободны и бесплатны.

В общем, предлагаю задуматься над архитектурой основного решения и реализации части функций в чем-то специализированном, варианты для выбора есть.
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

st.inna

По поводу подключения к акксессовской базе через LO BASE: да делала. Тогда еще стоял Windows и под него версия LO. Именно тогда я и увидела, что из той базы я вижу только таблицы и данные в них. Вся красота с формами, запросами и отчетами делается в BASE. Опять же, если я правильно понимаю.

Теперь на машине установлена астра и обращаться к файлу Access возможность пока есть (установлена виртуальная машина Win), но понимая тенденцию к полному его отключению после завершения действия лицензии (гос. предприятия больше не будут их продливать), такой вариант работы больше не рассматривается.

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

Т.е. создание и наполнение БД прошло успешно  :)

Теперь только вопрос в создании отчетов нужных форм, а для них нужны запросы. Вот тут то затык и произошел, чего сама не ожидала. Для работы в SQL для Access пришлось переучиваться со стандарта Oracle (был такой опыт работы), думала ну куда уж еще дальше можно урезать рабочие функции, но вот FireBird знает их еще меньше...

Такой вопрос, если мне сейчас с почти готового функционала базы c FireBird переходить на PostgreSQL (опять же не без помощи IT-специалистов моего предприятия, потому что про сервера я ничего не поняла...), насколько болезненнен этот процесс? Если ли возможность перенести туда уже существующие таблицы и потом через подключение к PostgreSQL работать через формы, запросы и отчеты BASE?

Огромное спасибо economist за такую подробную разъяснительную работу. Когда у непрофессионала что-то начинает получаться, это так затягивает  :)

mikekaganski

С уважением,
Михаил Каганский

st.inna

Все выполнила по указанной инструкции, но получила ошибку (на рисунке). А поясните, пожалуйста, для начинающего: что даст такое создание базы данных?

economist

Штатная библиотека макросов Access2Base по слухам покрывает "почти весь" API MS Access, то есть Формы можно или использовать, или перевести на другие объекты, из Access2Base.

Возможно, Формы ввода и Отчеты проще заново создать в Base (или внешних построителях, и десятки свободных). Ведь самое сложное (SQL-запросы) уже готовы и их несложно адаптировать под любой SQL-диалект любого движка.

PostgreSQL - самый мощный и самый сложный движок БД (из свободных), возможно стоит начать с простого SQLite, особенно если одновременных пользователей немного (4 читают или один пишет одновременно, иначе таймаут 1 секунда).

Или начните с MySQL, если у айтишников есть опыт. Часто к-либо сервер БД на предприятии уже есть и работает, просто вы об этом не знаете. Тогда нужно попросить права на пяток таблиц, подключиться (можно из Base, но специфические dBeaver, SQLiteStudio, PHPMyAdmin могут зайти лучше) и дальше будет проще, т.к. вопросы архивирования, доступа по сети итд - уже решены сервером.

FireBird, кстати, имеет развитый функционал, и функции там есть все какие нужно. Если в ней у вас почти все готово - просто поставьте сетевой движок FireBird Server и ODBC-драйвер и переключитесь на него, это несложно, много русских мурзилок в Сети есть. Также в Сети есть истории успешной миграции с простых движков SQLite/FireBird на сложные MySQL/Postgre, их стоит иметь ввиду, выбирая прямо сейчас. Но это будут только таблицы и данные. 
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

mikekaganski

Цитата: st.inna от 25 мая 2023, 15:46Все выполнила по указанной инструкции, но получила ошибку (на рисунке)

Прошу прощения, что не прокомментировал ссылку.
Я не специалист в Base, и даже не пользовался UCanAccess. Просто я недавно увидел тему по ссылке, а здесь подумал, что этот вариант может оказаться интересным. Так что лучше не обращайте на ссылку внимания, пока не появится реальная необходимость попробовать что-то ещё.
С уважением,
Михаил Каганский