Description: What I need: I would like to define different default values in different subforms for the same table. And - as a last fallback - the default in the table, which should be used, if neither an Input from the user comes, nor a default in the form is defined. Fact is: The defaults in the table are overruling the defaults in forms Steps to Reproduce: see attached database (different defaults in table and form are already defined) Actual Results: defaults in table are overruling defaults, coming from form Expected Results: the other way round Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 7.0.3.1 Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: de-AT (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 167476 [details] database with predefined defaults
Maybe you need a more concrete example for what I need: I would like to see in a special field in the table, where the record came from: a.) did it come from a manual input via a form b.) did it come from an upload directly into the table
If you will set the standard as the SQL-default it will work. open TOOLS → SQL and write something like ALTER TABLE "Tabelle" ALTER COLUMN "Datum" SET DEFAULT CURRENT_DATE; ... and: please write down, which database you are using. Firebird isn't the default database at this moment. Firebird is set back to experimental ...
Created attachment 167486 [details] the same with HSQLdb
Created attachment 167487 [details] it looks like FIREBIRD is not out of scope
I tested the behaviour with HSQL db and it is the same behaviour. And - by the way - I got the message to move to firebird see the attachments some tickets ago I asked, if I should continue with sending tickets about firebird based LObase. I got green light at that time. Please tell me if I should stop continuing with tickets about bugs coming from a firebird based LO.
Only in a development version of LO you could create Firebird databases without activating the experimental features. The migrating wizard is also an experimental feature. If you don't write down which database you are using we are thinking: The bug is described for the defaul database in LO, the (old) internal HSQLDB. Seems the version you selected is wrong. The screenshot you made is from such a development version, not with LO 7.0.3.1 The behavior in this bug-description is the same in HSQLDB, because this is part of the GUI since the beginning of OOo: Creating a table in the GUI offers a field for input a value, which should be written in a new row of the table when a new row will be opened for input data. And so the new row in a form will be created with this values. The controls in the form will recognize: There is a value, we shouldn't set a new standard value. The standard value will only work for fields, which are NULL and for new rows. The real default value you are looking for isn't the value you created in the GUI of the table. It must be created by Tools → SQL. This will set the default when submitting the new row to the database with fields, which are NULL and shouldn't be NULL. I won't confirm this behavior as a bug.
(In reply to Robert Großkopf from comment #7) > I won't confirm this behavior as a bug. That's why I sayd in the headline "probably works as intended". I followed your hint now and recognized, there is a difference between the "default" defined in table gui and defined via Tools/SQL. ============================ So I agree - its not a bug - it works as intented. ============================ It's misleading to use the same word "default" for different meanings and impacts. But I don't have a better suggestion for another word. ~~~~~~~~~~~~~~~~~~~~~~~ About testing based on FIREBIRD embedded database. I started developing my database when Firebird was communicated as the database for the future and I used firebird specifics. I will not put effort in a redesign back to HSQL. Please tell me, if I should stop raising tickets about errors I find during my work. As long I don't receive a message in this direction, I am going to continue raising tickets also for FIREBIRD related problems. BUT I promise to outline, that I am working based on Firebird.
(In reply to Richard Demattio from comment #8) > > Please tell me, if I should stop raising tickets about errors I find during > my work. We are interested in bugs of internal Firebird database. But it would be good if you test the same with a (small) HSQLDB. If you don't see the same effect there write down in the title for the bug: FIREBIRD: ... There are many bugs, which aren't solved at this moment for Firebird. So Firebird doesn't work as expected yet. And nearly nothing is solved here for over a year. The internal HSQLDB is working much better in the GUI of Base. I will set this one as "NOTABUG"