Field properties changes

I am wondering why the Base field properties change after I create a table - then save in both the table creation window and in the database window before closing the database - they change back to a default setting and the field width changes back to “automatic”? Any data that was entered seems ok, it’s the field properties that won’t stay as I created.

I have uninstalled the program v7.2.5.2, reinstalled the same version but the problem has is still there.

Could Windows 10 be causing this by accessing old files that were changed?

Getting very frustrated with this problem as I haven’t noticed anyone else posting the same problem and I have read the documentation numerous times so I’m fairly certain I’m following the correct procedure. Please help!


Have just tested with:

Version: (x64) / LibreOffice Community
Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

and saw no problem. However, it is not clear what your issue is. Please provide more specifics on what is set, the actual value set to and what is seen after re-opening. Such as Field name is my_amount as numeric with a length of 10 and 2 decimals with a default value of 12.00 (this is basically what I tested & it was OK).

Thank you for the reply. I’m a newbie to Libre Office so hopefully you can bear with me. I’ll try to do a screenshot of my table first.

ID is Integer w/ Autovalue, 10characters, right alignment, 1.30 cm width
YEAR is Numeric w/ no autovalue, 10, center align, 1.50 cm width
value is Decimal, no, 10, 2 decimals, right, $, 1.75 cm
Prefix is Text(varchar), no, 40, left, 2.30 cm
S/N"s is Text(varchar), no 40, left, 2.00 cm
Sigs is Text(varchar), no 40, left, 3.50 cm
Cat # is Text, no, 30, left, 1.80 cm
Portrait is no, 40, left, 3.60 cm
Reverse is no, 40, left, 4.60 cm
gradeis no, 25, left, 2.50 cm
certifr is no, 15, center, 1.40 cm
printr is no, 10, center, 1.25 cm
fpn is no, 10, right, 1.00 cm
bpn is no, 10, right, 1.00 cm
cost is no, 10, 2 decimals, right, $, 1.60 cm
sale pro is no, 2 decimals, right, $, 1.60 cm
comments is no, 100, left, 11.00 cm

I hope you are still awake! Im not a typer.

Cost and Sales Pro are both Decimal and set for 2

the screenshot is of a table that is correct. I will send one that isn’t.

Need to know the problem also. This is not table properties. It is the table view. Display here is based upon how th table itself was designed or hw you atered this view.

The properties revert to their original settings (In the “Value - Cost - Sale Pro” fields, Currency turns back to Number with alignment changing back to Left) In the Comments field the width changes back to “Auto”

This is just a table view. In most cases it is hardly used. Forms with a table grid is more practical. But let’s ignore that.
I could duplicate your issue and also resolve it. You are probably saving at the wrong time. You can make your changes to the View and before closing it, select the main Base screen and Save. then you can close all and re-open. All (at least in my tests) appears as set.

The only entry, which won’t be saved, is “default” for alignment. See bug 147282. Any other alignment will be saved in the table and will be executed in the table view.

Formatting will only be saved for tables. Queries and views will get the formatting from the tables. If GUI isn’t able to detect the original field in a query it will switch back to left alignment. So also sometimes dates will appear in a query as INTEGER if GUI can’t see the original field of a table there. You could set the format in the query, but it won’t be there when executed the next time.

Use a form for having a look at your data. Table controls in a form will save the format well.

First off I want to express my sincere thank you to Ratslinger and RobertG for helping me with this problem.

When I save a newly created table without data I need to close it and save in the main database window. If data is added to the new table before closing it can be saved, then closed and also save the database. Then I exit Libre, the next time or the next day the changes happen to the field properties that I set.

I like the table for entering data as it is easier to see the entered data and use copy/paste to avoid typing. I have created a form to work with but still prefer the ease of working with the table.

Not sure how else to describe this problem.

This shouldn’t happen. I have tested again with a table: Marked a column header in table view, right mouse click and set formatting for this column to align right. Works. Closed the table. Saved the database. Closed the database and LO, then restarted LO and opened the database. Formatting is as expected.

You don’t need to reopen the table for editing, only for input data. The format will be saved also the way I described. Tested with LO on OpenSUSE 15.3 Linux.

I could also see this formatting when extracting the database file ad open the content.xml in a text editor.

Are there special formats, which won’t be saved?

You could also upload the database here to have a look. Or you could send it to me per Mail.

Thank you RobertG for your help. I am busy this afternoon but I will put some info together including my database file. It was created yesterday, and after turning the computer on today there are changes to the properties in (3) tables in the database. (1) is fine! Hopefully you will be able to see what I’m doing wrong or missing.

Don’t expect anything for a day or two.

ps: on the attachment I have written which fields have had their properties changed.

I missed something on that attachment. All of the fields have been “reset” to “Automatic” from what I had designed.

I can’t send anything to the email address “no reply”. Can you email me an address that will work.

As an extension to my previous comment, I can in Windows 10 and now also in Ubuntu 20.4 (with both HSQLDB and Firebird embedded) duplicate the problem.
An interesting item here is that with enough fortitude to keep making changes (no seemingly amount or pattern) the problem ceases to be a problem (at least in my limited tests). I can then move to a different table even in the same Base file and have new problems there until something clicks and the problem ceases.
Definitely buggy.
Just tested PostgreSQL with native connector and could not duplicate. Tried many changes and multiple tables.