Field properties changes

Kacee · February 15, 2022, 8:24pm

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!

Ratslinger · February 16, 2022, 12:42am

Hello,

Have just tested with:

Version: 7.2.5.2 (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).

Kacee · February 16, 2022, 12:45am

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.

Kacee · February 16, 2022, 12:57am

Kacee · February 16, 2022, 1:11am

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.

Kacee · February 16, 2022, 1:13am

Cost and Sales Pro are both Decimal and set for 2

Kacee · February 16, 2022, 1:14am

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

Kacee · February 16, 2022, 1:16am

Ratslinger · February 16, 2022, 1:17am

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.

Kacee · February 16, 2022, 1:20am

Kacee · February 16, 2022, 1:23am

Kacee · February 16, 2022, 1:28am

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”

Ratslinger · February 16, 2022, 2:07am

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.

RobertG · February 16, 2022, 7:42am

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.

Kacee · February 16, 2022, 8:00pm

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.

RobertG · February 17, 2022, 6:58am

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 7.3.1.1 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.

Kacee · February 17, 2022, 5:35pm

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.
Ken

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

Kacee · February 17, 2022, 5:53pm

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.

Ratslinger · February 17, 2022, 6:42pm

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.
.
Edit:
Just tested PostgreSQL with native connector and could not duplicate. Tried many changes and multiple tables.

CharlieH1976 · February 19, 2023, 11:37pm

I have the same problem. Just created a new database from a .csv of an old library catalogue for my home study/library. I made sure I input the width during the creation process and also viewed the finished table and adjusted width. If I saved during the editing and kept the database itself open, the table remained in the same state as I had left it (even if I closed and reopened the table.) However, if I save and close the database, then the table reverts to a “standard” width - which seems to reflect the length of the field name and not the width of the text inside the field, so titles of books are reduced to the length of the word “Title”, but a year (e.g.; “1990”) in a field entitled “Published” gets plenty of space because the word “Published” is longer. As this is a book catalogue, it is important to a) be able to see the full title and to have other details visible in full and b) to see all the records at once. It is frustrating and time-wasting to have to reset all the widths every time I want to look at this list.
It is odd that the originals were created in an old version of MS Works and it was able to do everything I have described. LO (ver 7.3) is newer and I have had these problems - not to mention not being able to import .csv straight into Base, but having to go through Calc first. (I was able to find a version of MS Works to create the .csv files in the first place, but assumed that moving to LO was a way of future-proofing my databases!)