A simple question

But one that intrigues me from a conceptual point of view.
.
I provide the following details:
.

  • I’m not talking about a Writer document, but about Base.
    .
  • I really wonder about forms which generally contain a main form associated with a table and can have sub-forms with master and slave fields, buttons, queries, etc.

Are there advantages or disadvantages of having more than one mainform in a form document and each being able to have subforms?
.
Is this common practice or generally unnecessary?

And if it does regularly, what would be the main use?

I use Windows 11 with LibreOffice 7.5.4.1

Are you really asking for the database interface component Base as suggested by your tag base? It looks rather like a generic question for Writer, though forms can also be designed in Base with the Report Generator.

Please, edit your question to give more details. Don’t forget to mention OS name, LO version and save format. Don’t do that with a new comment, but indeed modify your question. This site is not a forum and question can be edited any time.

@Renel

Like anything else it all depends upon the needs of the task at hand. Each main form can be assigned to a different table, view or query connected to that Base file.
.

Again, it is all dependent upon needs. I currently use it to have data displayed on one form and another to display a list of totals for the data displayed.
.
Have used this in other situations as well. Have a tabbed type interface with each tab selected (all via macros) goes to a different internal form (have four) displaying a different set of information. Such as one form to maintain data and another for to search through through information and link to other locations. All personal preference.

1 Like

This is the way how relational databases use to work since the 70ies. Everything depends strictly on normalization.

[Example] Relations reflected by list boxes in forms

It is very simple, however rather abstract, so most of todays users can not understand.

2 Likes

So if I understand correctly, there is no limitation, everything is according to the needs and the usefulness that can be drawn from it as long as the relational structure is correctly established and/or normalized.

@Ratslinger, the few examples you gave me give me a good idea of the possibilities to make some changes to my database.

@Villeroy, I also appreciate the links you suggested to me. I had already read the link regarding relationships reflected by list boxes in forms. I am currently analyzing your DB Power Filter. I want to try to integrate this use of lIstboxes as a filtering tool for certain needs in my DB.

The implementation looks very simple in your DB, but it doesn’t transfer so easily into the structure of another DB. I have to understand how it works and the SQL commands that are the heart of this operation. For me, it’s a lot of work, because I’m not a programmer, but I have the patience and I take the time…

Problem: Base has 3 methods of filtering records but no method for filtering by form controls. All Form controls write some value into some column of the current record. Subforms filter existing records by master/slave fields. Let’s utilize this limitation. We create a table with one record where our form controls can save entered filter criteria. The values entered into the single record can filter a subform.

Create a table to store sets of filter criteria with max. 2 integers, 2 dates, 2 case insensitive strings and a primary key (NOT automatic).

CREATE TABLE "Filter"( 
INT1 INT, INT2 INT, 
D1 DATE, D2, DATE, 
TXT1 VARCHAR_IGNORECASE(10), 
TXT2 VARCHAR_IGNORECASE(10),
ID INT PRIMARY KEY
)

Add a first row with ID 1

INSERT INTO "Filter" VALUES NULL, NULL, NULL, NULL, NULL, NULL, 1

Create a main form with the following properties:
Source type: SQL
Source: SELECT * FROM “Filter” WHERE “ID”=1
Turn off all abilities except “Modify data”. In this form we must not tab beyond this single record. We must not delete this record and we don’t need any navigation bar for a single record.

Simple solution for a subform filtering one table:
Source type: Table
Source: Table name
Master fields: INT1, D1, TXT1
Slave fields: <corresponding integer, date and text of our table>

This solution is too simple because it does not show any records unless every criterion has a value. You have to fill out INT1, D1 and TXT1 with reasonable criteria in order to get any record set.

Create a parameter query (query with place holders):

SELECT * FROM "Table name" 
WHERE (:pTXT1 = "text column" OR :pTXT1 IS NULL)
AND (:pINT1 = "integer column" OR :pINT1 IS NULL)
AND (:pD1 = "date column" OR :pD1 IS NULL)

Now for the form:
Source type: Query
Source: Name of above query
Master fields: TXT1, INT1, D1
Slave fields: pTXT1, pINT1, pD1 (corresponding parameter names without leading colon)
The expression (:pTXT1 = “text column” OR :pTXT1 IS NULL) returns TRUE when parameter :pTXT1 is missing.
If all 3 parameters are NULL (missing), the WHERE clause evaluates to WHERE TRUE AND TRUE AND TRUE, so all records are shown indiscriminately.
If INT is entered in the master form as 42 the WHERE clause evaluates to: WHERE TRUE AND (“int column” = 42) AND TRUE which shows all records where “int column” equals 42, ignoring the other 2 parameters which resolve to TRUE because they are NULL.

Searching for substrings:
WHERE (’%’ || :pTXT1 || ‘%’ LIKE “text column” OR :pTXT1 IS NULL)
The literal % is the same as * when searching for file name patterns.
The || concatenates 2 strings (same as & in spreadsheets).
The LIKE operator is used for pattern matching. An equal sign would match literal % signs.

Searching for date ranges:
WHERE (:pD1 >= “date column” OR :pD1 IS NULL)
AND (:pD2 <= “date column” OR :pD2 IS NULL)

Need another criteria set for another form? Add a filter record with ID=2 and use that filter row for the filtering main form: SELECT * FROM “Filter” WHERE “ID”=2

1 Like

I do believe that in the context of my DB, using one or perhaps two other main forms in the form document to implement this filtering system would simplify the organization and maintenance of the form ducoment. Currently in my DB, I have two subforms in the main form where I want to implement this system and keep this filtration independent of each other. It is not necessary and unimportant that these remain in the current main form.
.
So, I believe I understand the importance and operation of the filter table and I will need another set of criteria for the second subform. They will become two subforms each associated with a main form with their own ID as content.
.
Thank you for the explanation regarding how the filter table and query and filter parameters work. I have a better understanding of the SQL command and especially the importance of the WHERE clause in this filtering function.
.
THANKS!