Opening forms withouth saving data in libreoffice base

Gigiux · November 12, 2021, 1:34pm

Hello,
I would like to use a series of forms to input data. The outline I would like to use is that the form is supposed to be a series of linked screens. Thus, on screen 1 I will add things like name and DOB; on screen 2, address and telephone and so forth. I can open a new screen with the macro:

Sub openHISTORYFORM
	const sNewDocumentName="historyForm"
	oNewFormDocument=ThisDatabaseDocument.FormDocuments.getbyname(sNewDocumentName).open
End Sub

This works but, upon opening the second screen (historyFORM), the data are saved. So, in the end, I have two records instead of one, each with half the fields.
Is there a way to

open the second screen without saving the data
close screen 1 when opening screen 2
Thank you

RobertG · November 12, 2021, 2:06pm

What will you do with the unsaved data in form1? Should it be used ind form2?

Seems what you want to do is something like a dialog with step1, step2 …

Gigiux · November 12, 2021, 3:30pm

probably the name is a dialog – I forgot to mention: the data should be saved all together when closing screen 2 so to have a single record with all the information.

RobertG · November 12, 2021, 4:53pm

Dialogs need much coding in Basic. So many people try to get the same behavior in only one form. If the form expands too much for you, you could switch between different “steps” by setting form controls visible and other controls invisible.

Gigiux · November 12, 2021, 9:09pm

Ok, so how does it work? Besides I understood Base works with Java…

Wanderer · November 12, 2021, 10:48pm

No, but…

Base does not need Java. For example I connect to a sqlite-Database through odbc-driver without java.

But the default embedded database hsql is written in Java. So if you use this database you need java. (I guess one of the ideas behind switching to firebase was getting rid of java).

If you connect to a database through jdbc-driver instead of odbc you will need java

The report-engine of base needs java. So, if you want to use it you need…

There are also Extensions, written in java, so you need java to run them…

Gigiux · November 19, 2021, 2:00pm

the data should remain in memmory and saved at the end, on the last screen…

Villeroy · November 13, 2021, 12:54am

You can make the logical form read-only. Open the form for editing and disallow modification, insertion and deletion in the data properties.

echo8hink · November 14, 2021, 6:03pm

You may want to look into using the Access2Base library included with LibreOffice. There are some interesting examples on the Tutorial page of the support site. See the tutorial for: Simulate Tabbed. This example has the appearance of two forms, when actually using sections of one form.
http://www.access2base.com/access2base.html

Gigiux · November 14, 2021, 7:05pm

Thank you!

Gigiux · November 16, 2021, 2:10pm

On second thought, I think this approach is too complicated. Instead of filling a large form with several screens, I think BASE is more oriented towards having smaller dedicated forms. The different tables are then linked via a foreign key.
The problem is: how do automatically assign a key to a table that is then automatically assigned to the linked tables? If I have an ‘Update cascade’ and ‘delete cascade’ relationship, would that work? and which one should be the parent? I now have a 1:n from the ‘main’ (the parent) table and the ‘sub’ table (child).

echo8hink · November 16, 2021, 4:04pm

I would recommend a series of YouTube videos on LibreOffice Base by TheFrugalComputerGuy. Even though the videos are a bit dated, and there are a lot of them, they are relevant because Base has changed very little over the years. I learn something new every time I watch them.

There are a couple of “Junction Table” videos (63 and 64) that may help you set up a form for many-to-many relations. A simple move of a refresh button in the navigator (video 64) is all it takes to keep the “save changes” pop-up from appearing.

There are examples of using list boxes in table controls to show sql linked fields in the columns, etc. I know it’s not a quick solution, but you may find a way to address your problem. I have learned a lot of things that Base can do if you can invest the time to learn how to use its (sometimes less than obvious) interface.

Cheers!

Gigiux · November 16, 2021, 5:09pm

Thanks, I also learned base from the frugal computer guy but it was a decade ago (!!). I’ll watch them again. The video number will help me.

Villeroy · November 16, 2021, 9:17pm

Most Videos don’t teach conceptual knowledge. In the context of a forum a single document with dummy data tells more than 1000 words. A document attached (no screenshots) makes it easy to see conceptual problems and develop drafts for working solutions.

Gigiux · November 17, 2021, 1:58pm

I am attaching a working example. I have a parent and child table. The parent_ID field should get the same value in both tables automatically (more than many to many as in videos 63/64 should be 1:1). I linked the table but I can’t save the data…
WE2.odb (24.2 KB)

Villeroy · November 17, 2021, 9:29pm

70427.odb (30.7 KB)

Info in README form.

Gigiux · November 18, 2021, 9:59am

Thank you! so PERSONS is linked to ADDRESSES via ID and to phones via PID. ID is a primary key but PID is not, but ID is in autovalue only on PERSONS. there is no cascade among the tables. In my version, I don’t get any linkage. the only table updated is the child and it does not get ID from the parent…
WE.odb (12.2 KB)

Villeroy · November 18, 2021, 11:24am

Because the only table on that form is the “child” table and there is no link to any other table. I find the analogy by names of “child” and “parent” table a little bit confusing.
In my database one form document uses the persons as parent form and the other tables as children on a subform whereas the child-parent relation is reverted in my second form where the phones are on the parent form, persons on the subform, optional addresses on a sub-subform.
Are you aware of the form navigator? It is the single most important tool for form design. The screenshot shows the form navigator of my persons form…
“Forms” is just an abstract container, the root element of all forms. “MainForm” and “SubForm” were created by the form wizard. I added the Phones_Form later.
Bildschirmfoto von 2021-11-18 12-03-59
Any form having a parent form (here “SubForm” and “Phone_Form”) have two lists of linked fields which determine the relation to the parent.
“MainForm” is linked to PERSONS and “SubForm” to ADDRESSES and the subform is linked through their common ID fields analogue to the one-to-one relation between the two tables (see SubForm’s data properties)… Each person may have one or zero related postal address.
“Phones_Form” is linked to “MainForm” by its foreign key “PID” (person ID) analog to the one-to-many relation between tables PERSONS and PHONES. Each person may have many phones, therefore I display the phones in a pattern control bundled within a table control.
The concept of forms and subforms can be a lot more complex than just mirroring the table relations. However, mirroring table relations in order to make multiple tables editable at the same time is the ain purpose of this construct.
There are many example databases and tutorials in the tutorial section on forum.openoffice.org I got the most positive feedback for this one: [Example] Relations reflected by list boxes in forms
P.S. and this one: [Tutorial] Forms in OpenOffice.org Base (View topic) • Apache OpenOffice Community Forum

Gigiux · November 19, 2021, 1:39pm

alright, I am lost here. I understand subforms, but the original idea was to avoid having a subform and work instead with independent screens/forms. The ‘parent’ table is called parent because it generates the key that is inherited by child when passing from one form (filing the fields of patent) to another (filling the fields of child) and then to another (filling the fields of child 2) etc. Essentially, the ID fields of the children tables is just equal to the ID field of the parent. But looks to me it is not an easy task to generate such link. perhaps it is better to revert to the original idea: a single large table filled by screens not forms (that is ‘forms’ that do not require closing tables and saving data immediately, but simply displaying input icons sequentially until a final push button is reached). Thanks anyway for the links, I’ll read them

Villeroy · November 19, 2021, 2:17pm

Avoiding the most important feature makes no sense at all. Go with the flow if you want to get things done.