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 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.
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.
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.
.
Edit:
Just tested PostgreSQL with native connector and could not duplicate. Tried many changes and multiple tables.
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!)
Have to say I thought I was the only one having this problem. But after downloading the latest version I was pleased because it was working as it should for a week maybe. Careful not to open an old Libre Base file, I created an entirely new table and form. Even with closing Libre and turning off my desktop. But into the second week it went back to the same old tricks again, lost the width for each column as well as data position in the cell ( left, right, center). I have given up and am using a spreadsheet from an old version of Excell. I get the impression that Base might not be that popular or surely the knowledgeable creators would fix it.
There are not to many developers working on base… However I think you missed important lines by RobertG and Ratslinger:
So the recommended way is using forms for input. If you need a grid, there is also a grid-control to be put on the form. And there you can also re-arrange columns.
As there already is a way to reach your desired way to edit there may not be put much work into improving table-view. (I use it to check on imported data and sometimes to copy rows to spreadsheets, but for nothing else.
If Works did everything you need, ask M$, why they do not support it…
.
The point is not Base being “newer” (I’m not so sure, as I’ve seen StarOffice first on OS/2 Warp with Adabas-Database… ), but having different concepts: For most people Works/Access “are” databases. I would describe Base as a connector to different databases, wich usually hides to Open/LibreOffice the nature of fhe file.
.
So I can query a csv-file, dBase-Table, embedded-HSQLDB, sqlite via odbc, MySQL or PostgreSQL either locally or remote on a server. As all this sources differ it limits the support you get from the connector (Base), but it also expands the possibilities you have for the Office-suite.
.
??
.
Base can access csv directly. You select connect to an existing database and set the folder with the csv-files as “the database”. The .odb will only store your connection and queries you create. The data stays in your csv.
.
Also the default hsql-embedded can attach text-tables internally for import, as described in the guide to Base (You checked the documentation on LibreOffice.org ?).
.
The mentioned way via Calc therefore is the third possibility and most connected databases have additional ways, so another option to access csv may not be the highest poriority on the list.
.
To be prepared for the future I like to have more than one option. So I use Sqlite and MariaDB with Base and LibreOffice. I can also use Tools like SqliteStudio and HeidiSQL or DBBeaver to access data and everything is available with bindings to Python, if I need to develop something on my own. So no real problem using Base - especially not, if you compare to MS-Works.