Created attachment 56592 [details] Default_value - on table in GUI, second in SQL. Try to change relationship to "set default" When editing the relationship between two tables you could choose: On update - default. I tried this with a foreign key edited as delault in the GUI. The GUI shows this default-value. The editing of the realtionship doesn't work. A popup appears: Missing DEFAULT value ... When trying this with a table, where the default-value is set by SQL you could change the relationship to "On update - default". Seem the default-value in the GUI is only set as a GUI-value. It appears when editing a new row during editing. When you don't whish the default-value in GUI you have to delete the default-entry in the row first. The default-value created in SQL isn't shown in the GUI. The default is set when saving the new row and the field is already empty. This is the right behaviour of tables. If you want to use a GUI-default you could better set the default in form-controls.
Right - this is really more of a UX defect IMO. As I think you have found the 'Default Value' property in the table editor is used only to feed the GUI controls and is not used when creating/editing the table DDL command. It's also then a fact that the Default Value entered in the table editor property can only be a string value, you can enter a string representation of a numeric value of course. The reason, again IIRC, that this property ended up on the table property editor is that is must be available to all and any GUI controls in the applicaton - a dataview (dbl click a table, the beemer displayed in Calc/Writer, form wizard use, etc). It is also the situation that Base can work with datasources that are not full blow RDBM and may not have a built in default value feature. Setting the value in the table definition property editor where all other setting are used to when defining the actual table structure in whatever back end used is however, IMO, also the big UX problem. When using a RDBMS that does support def-vals in column definitions the users think, naturally, that this value would be used for such purpose. This comes up very often when dealing with users. The help text displayed in the property editor really isn't a lot of help here either: [English text follows] "Enter a default value for this field. When you later enter data in the table, this string will be used in each new record for the field selected. It should, therefore, correspond to the cell format that needs to be entered below." It's technically accurate but doesn't really seem to impart the information in a way that helps. That and the layout doesn't really help to get the user to read it, as if most would anyway :) So, I think it would be worthwhile to come better wording, tho I'm not at all convinced it would lesson the confusion on the users part substantially.
Thanks for bugreport Sorry, but I can not understand problem for reproduce it. As I understand exist some problem with default value, different for sql and UI. I unpacked attached database, but can not find difference there. Please, write step-by-step instruction how to reproduce this problem, used sql instructions for create table and show description of table. And in step when problem appears: what expected and what actually produced. Thanks in advance. Best regards
Created attachment 58586 [details] Shows the difference between default-value in GUI and in SQL
Thanks for explanations and screenshots. Trying to understand ...
Sorry, but I can not find how to produce error message, shown on 1-th page of screenshot. Please, write step-by-step instruction how to produce this error.
Created attachment 58689 [details] Way to test default-value in the GUI. Try in relationship to set the link to default. I have tried to show it in pictures. When you link the tables in extras - relationship all seems to be OK. When you want to edit it and set the values to default (Update or delete the primary-key should set default) it does not work, because there is no default-value defined in the database. The default value in the GUI is a shown value in the GUI and would be saved with saving the data. It is not integrated in the database. When it is integrated in the database with SQL it is not shown in the GUI, but will appear in the table after inserting a new row. It is not only a problem in the relationship. Its also a problem with default in date- or timestamp-fields. In SQL you could set it to now(), the current date ore timestamp. In GUI you could set it only to a fix date. I do not know if there is anybody who uses a fix date as default ... Robert
Thanks for additional explanations. I have reproduced this. IMHO happens this: In attached database, when unarchived, we see xml files where saved GUI settings and binary files, where contains database itself. When we change something, using GUI, it saved inside of one of xml files (I can not find where). When changing using sql, changes saves in binary files. Tools->Relationship window uses setting from binary file. May be default value during GUI editing not saves somewhere at all. Functionality not implemented yet. Or it works only with some specific database driver.
@ Lionel Please, take look at this bugreport when will have time. One setting from UI for table not saves to database.
I have had a look in the *.odb-file. The settings of the Default-value, when editing a table, are saved in content.xml. This is only saved for the Base-GUI, not reachable to the database. Could be a better idea to save this by SQL in the database, when using the table-editor of the GUI. So you would be able, for example, to save a timestamp as default, which isn't possible yet. You could get the same behavior for input values with a GUI-Default, when you use a form and set the fields of a form to a GUI-Default-value. The only difference is, that you couldn't see the GUI-default when opening a table. I have changed the version to LO 3.3.0 (it never worked in another way in any version) and set it to "enhancement".
Adding self to CC if not already on
*** Bug 94750 has been marked as a duplicate of this bug. ***
Nothings happens for this bug for a long time. "Default" in a table isn't the same as "Default" in relationships (and databases). The simplest way to solve this bug a little bit is to rename the "Default" in the table to "Proposal". This value will be created by the GUI, will be seen when creating a new row for the table. "Default" in a database means: The value will be written, if there is no input (NULL) in a field while inserting new data. Should we change the component to UI? Don't know where the decisions will be made to rename something in GUI.
The fact that the "default" set in the table properties is not the database (sql) default is in my opinion confusing... When the underlying RDBMS does support default values, well, it should just be synchronised. But this means that LibreOffice cannot just consider it a string, it has to handle its proper typing. On the other hand, I understand the need for a "LibreOffice GUI default" when the database does not support default values. So maybe we should just "duplicate" this default property: * GUI Default * RDBMS default
(In reply to Lionel Elie Mamane from comment #13) > So maybe we should just "duplicate" this default property: > * GUI Default > * RDBMS default I pretty much agree. At the moment there are really two different defaults, but they are given one name: Default, which is confusing. 1) As a first solution step, and as Lionel suggests, there needs to be a different name for each of these two different Defaults, to help clarify that there are two of them and to allow separate descriptions of what they do, and how they can be set and used. 2) Then as an additional solution step, figuring out how to base the GUI Default on the RDBMS Default would also be a good thing I think, as it really makes no sense to me that there would exist a GUI Default, when there was already a RDBMS Default in action. If no RDBMS default exists, then a GUI Default can emulate it.