Попытка работы с автономными формами

[st.inna]

Сделала две автономные формы к существующей базе данных.

Открываю «Файл1» — это форма входа в БД, где вводятся логин и пароль. При нажатии кнопки «Вход» происходит проверка правильности введенного пароля и открывается «Файл2». Мне нужно, чтобы значение логина, введенного в «Файл1», перенеслось в «Файл2» (ну типа видеть какой пользователь вошел в базу). Обращение к элементам на форме, находящимся в самой базе, и к элементам на автономной форме совершенно разное, и моя беда в том, что я не понимаю как «общаться» с по-сути документами Writer.

Мои действия такие:

Название формы (название, которое мы видим при открытии навигатора) документа «Файл1» я вытащила из события нажатия кнопки «Вход»:

   oControl = oEvent.source.model
   oForm = oControl.parent
   MsgBox oForm.Name      (выдает название формы «LoginForm»)   

затем в переменную «txt_User» запоминаю значение введенного логина:

txt_User = oForm.getByName("User").Text

и открываю «Файл2» через Url-адрес:

sUrl = ........
oDoc =  StarDeskTop.loadComponentFromURL(sUrl, "_default", 0, Array())

Теперь мне нужно «зашить» в макрос:

1. Сделать активным окно «Файл2» (он открыт, но активен ли он?).
2. Значению поля «User» документа «Файл2» присвоить значение переменной txt_User
3. Вернуться к документу «Файл1» (сделать его активным), закрыть его.
4. Вернуться к документу «Файл2» для работы.

И еще: как можно было бы обращаться к форме в автономной форме не через событие
   oControl = oEvent.source.model
   oForm = oControl.parent

а напрямую, типа

   oDatabase = Application.CurrentDb()
   oForm = Forms("LoginForm")
   txt_User = oForm.Controls("User").Text

но только в документе Writer.

Объяснила, как могла. Отвечу на уточняющие вопросы.

Если есть такая возможность «скакать» по автономным формам, то есть надежда сделать свою базу  многопользовательской (файл базы на сервер, а автономные на компы с копиями для каждого пользователя). Или я слишком наивна :-) ? 

[economist]

Можно читать юзера из переменной окружения и не городить формы авторизации. Права к данным прекрасно настраиваются в самих БД.

Автономные формы что будут делать кроме ввода, удаления, подбора строк?

У форм odt есть UserFields и Переменные - в них классно хранить инфу и легко читать/писать макросом.

[economist]

Если Форма во Writer крутая, содержит неск таблиц из разных БД (так можно) и по сути содержит Отчёты - то это целое Приложение, и его надо "спроектировать".

Имхо, именно такие автономные формы и надо делать. Если Форма будет много считать - лучше ее сделать как ods-файл.

Не все в офисных формах можно сделать прям красиво, но то что можно сделать быстро - это точно.

Изучите готовые встроенные события БД у кнопки во Writer. Там много интересного...

[sokol92]

Файл "базы данных" .odb выполняет следующие функции:

1. Содержит параметры для соединения с SQL базой данных (всегда).
2. Содержит встроенную базу данных (не обязательно).
3. Содержит один или несколько сохраненных запросов к базе данных (не обязательно).
4. Содержит встроенные формы и отчеты (не обязательно).

Автономные формы - это документы Writer специального вида, которые содержат объекты для "общения" с базами данных, параметры для соединения с которыми хранятся в одном (обычно) или нескольких .odb файлах.

Если база данных поддерживает многопользовательский режим (например, PostgreSQL), то автономные (как и встроенные) формы могут полноценно выполнять функцию клиентов этой базы.

Можно, но вряд ли стоит разрабатывать свою форму для ввода логина и пароля, так как при необходимости будет вызван соответствующий системный диалог.

Для более предметных обсуждений Вы можете составить тестовый пример (или найти готовый), содержащий .odb файл со встроенной базой данных (для целей тестирования) и автономную форму (формы).

Предполагается знакомство с замечательной книгой А.Питоньяка AndrewBase.odt.

Поищите также контекст "standalone forms" на форумах: OO и LO.

[st.inna]

Всем большое СПАСИБО! Буду изучать приведенные ссылки, есть интересные решения - надо опробовать. Если что-то получится, отпишусь.

[st.inna]

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

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

Весь смысл создания автономных форм для меня был в организации работы с базой в многопользовательском режиме (3-5 сотрудников), поскольку везде пишут, что при обращении к базе из автономной формы сам файл базы данных не блокируется. И действительно, при открытии автономной формы с двух разных компьютеров формы открываются и данные видны для каждого пользователя. Файл базы данных .odb расположен на сетевом ресурсе в папке, к которой есть доступ у всех кому нужно работать с базой, копии автономных форм у каждого пользователя на своем компьютере, база зарегистрирована на каждом компьютере. Проблема возникает при сохранении новых внесенных данных при одновременном "подключении" к БД: каждый пользователь (компьютер) вносит свои данные, сохраняет их, видит их потом, даже если вышел из формы и затем опять в нее вошел, но при этом он никак не видит данных, внесенных в базу другим пользователем. И это только первая проблема... Опишу подробнее: вошли два пользователя с разных компьютеров, они в сети, каждый через свою автономную форму для ввода данных подключился к базе, каждый видит все данные, затем первый внес строку с данными, сохранил ее - при этом видно, что файл .odb изменился (изменилось время сохранения файла), затем пользователь на втором компьютере внес свою строку с данными, сохранил ее - опять видно, что файл .odb изменился. Затем оба пользователя вышли из своих автономных форм. Открываю файл самой базы данных .odb и вижу, что на самом деле сохранились новые данные, внесенные только одним пользователем, причем закономерность такая: не важно, кто первым подключился к базе через автономную форму или кто первым вышел из формы, важно только то, кто ПЕРВЫМ сохранил свою новую запись. Если первый пользователь сохранил свою "первую" запись ПЕРВЫМ, затем второй пользователь ввел "вторую" и "третью" запись, затем опять первый пользователь ввел "четвертую" запись, так вот в базе окажутся сохраненными только "первая" и "четвертая" запись, сделанные первым пользователем. Т.е. кто первым начал сохранение, все записи того пользователя и сохранятся, не важно сколько он их ввел, важно, что первым начал сохранять.

В связи с этим у меня вопрос: так ли должны работать автономные формы? Или у меня вообще неправильный подход к организации работы в многопользовательском режиме? Не могу понять в каком направлении "биться" дальше или это вообще все зря. Если каждый пользователь по очереди подключается к базе и вносит данные, то все хорошо, но какой смысл тогда был городить автономные формы, если можно было также "по очереди" пользоваться самим файлом БД... У меня Linux, версия LO 7.4.2.1, движок Firebird.

[mikekaganski]

важно только то, кто ПЕРВЫМ сохранил свою новую запись. Если первый пользователь сохранил свою "первую" запись ПЕРВЫМ, затем второй пользователь ввел "вторую" и "третью" запись, затем опять первый пользователь ввел "четвертую" запись, так вот в базе окажутся сохраненными только "первая" и "четвертая" запись, сделанные первым пользователем.

Как мне кажется, тут несколько неправильная интерпретация: в приведённом Вами примере важно, кто сохранил последним.

И да, нельзя работать с встроенной базой (той же встроенной Firebird) в многопользовательском режиме. LibreOffice это не поддерживает от слова совсем; и если где-то написано обратное, это неправда. Единственная возможность работать в многопользовательском режиме - внешняя БД. Я думаю, сейчас Вам расскажут как именно такое настроить (вероятно, проще всего будет использование sqlite).

[st.inna]

Как мне кажется, тут несколько неправильная интерпретация: в приведённом Вами примере важно, кто сохранил последним.

Если первый пользователь первым сохранит свою единственную запись, а затем второй пользователь сохранит свою единственную запись, то в файле базы данных окажется окажется только запись первого пользователя, поэтому "кто первый, тот и папа"  В приведенном ранее описании, если бы второй пользователь сделал "пятую" запись, то сохранились бы записи только первого пользователя "первая" и "четвертая".

А все-таки как настроить работу с sqlite? Для чайника   

[economist]

На Форуме много раз писал про SQLite, напишу ещё, она и ТС заслуживает этого.

Комфортная работа в сети с нею - для 3-5 человек. В пике она дает одному сохранять и 4-м одновременно читать базу. Есть два основных способа - JDBC и  ODBC. JDBC обходит стороной админов...


Качайте с гитхаба jdbc xerial sqlite driver и в LO Alt+F12 - Расш... - Путь класса -  выбрать скачанный *.jar, рестарт LO.

Теперь подключаемся к пустой БД:

Файл - Создать - Базу - Соединиться - JDBC - Далее

jdbc: sqlite:D:/base.sqlite
Класс org.sqlite.JDBC

Оба теста (кнопки) должны быть Ок.

Пишу с телефона, мог что-то протупить

[economist]

Как быть с переносом таблиц имеющейся БД Firebird, варианты:
- поискать конвертер fb -> sqlite
- выгрузить в формате *.sql и загрузить
- использовать швейцарский нож типа DBeaver, SQLite Studio итд.
- вдруг можно перетащить таблицы мышью?
- обмен через txt-файл
- copy/paste?

Главный плюс SQLite - скорость и простота. Запросы там работают без идиотских кавычек, вот прям так:

SELECT *, 2, FIO, СУММА FROM Табличка

Из всего что нужно знать про SQLite - самое важное то что она быстрее всех, проще всех и всегда все хранит как текст. Тут утиная типизация. Она может удивить, скажем, на ИНН без и с ведущим нулем. Но при этом она ничего не потеряет.

Файл с базой нужно поместить на быстрый ssd hdd на быстрый сегмент сети. В Линукс все ок, но NFS не рекомендуется, хотя на нем работает ещё быстрее чем на samba.

Если база стала медленной - значит пора создавать в ней индексы. Это легко. Если нужно чтобы база сама, например, удаляла дубликаты - есть триггеры. Все эти фишки делаются запросами откуда угодно.

Встроенный в LO Питон работает с sqlite даже быстрее, чем ее родная консольная утилита, написанная на языке С. А ещё Python делает SQLite серверной, т.к. поддерживает WAL.

Почему все не на SQLite - ума не приложу. И почему в LO Base не она по дефолту - тоже.

Есть ли что-то ещё лучше и быстрее!? - да. Это DuckDB. Но утка ещё молода, пусть подрастет.

[sokol92]

Почему все не на SQLite - ума не приложу

Комфортная работа в сети с нею - для 3-5 человек

И почему в LO Base не она по дефолту - тоже.

+1

[st.inna]

Спасибо большое за помощь!

Качайте с гитхаба jdbc xerial sqlite driver и в LO Alt+F12 - Расш... - Путь класса -  выбрать скачанный *.jar, рестарт LO.

Куда сохранять скачанный файл? Или это не важно? У меня Linux
В строке "sqlite:D:/base.sqlite" ничего не должно поменяться, если я скачанный файл сохранила в /home/data?
Как-то пока ничего не получается...

[economist]

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

В вашем случае так:

sqlite:/home/data/base.sqlite

[st.inna]

Создать пустую базу получилось так:

Зашла на GitHub в поисках драйвера. Там написано нужно скачать два файла: sqlite-jdbc-3.45.1.0.jar и slf4j-api-1.7.36.jar. Сохранила их в /home/data. Оба эти файла прописала в "Путь класса", LO перезагрузился. Затем Файл - Создать - Базу - Соединиться - JDBC - Далее

jdbc: sqlite:/home/data/base.sqlite
Класс org.sqlite.JDBC

Все тестирования прошли успешно.

Копировать таблицы через copy/paste не получилось, всё время на что-то ругался. Попыталась создать таблицы заново. Тоже не выходит. Во-первых типов данных кот наплакал (целое, вещественное, текст, BLOB и SQL NULL). Создала два поля: целое "ID" (первичный ключ, автозначение) и текстовое "Фамилия". Сохраняю таблицу. Пытаюсь открыть для ввода данных - ошибка (рисунок приложила). Открываю в режиме правки - уже ничего не активно, ничего нельзя изменить, удалить или добавить.

Чего еще не хватает?

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

В вашем случае так:

sqlite:/home/data/base.sqlite

Да, база данных должна быть доступна для нескольких пользователей. У нас есть сеть, в ней есть папка с доступом для этих нескольких пользователей. Базу положу туда (если получится как-то воссоздать там таблицы с данными). А файлы драйвера тоже должны тогда лежать там или на каждом компьютере будет своя копия этих двух файлов .jar? На каждом компьютере нужно эти два файла прописывать в "Путь класса"? И не понятно
как эти несколько пользователей должны подключаться к базе: файл .odb теперь "многопользовательский"? Или опять через какое-то подключение?

[bigor]

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