Description: M Windows 11 PC is crashing regularly and I haven't had time to completely reload Windows 11 to try to fix. This has given me ample opportunity to note that this problem happens every time my PC crashes while Base is open. I'm in Sydney Australia Timezone, using embedded HSQLDB. Steps to Reproduce: 1. While Base is open, turn off PC 2. 3. Actual Results: format for all dates in base database changes from dd/mm/yyyy to dd/mm/yy Expected Results: Date column formats should remain dd/mm/yyyy Reproducible: Always User Profile Reset: No Additional Info: Where are the column formats stored? They don't seem to be in the .odb file as if I recover the database, then restore the .odb, dates are still in dd/mm/yy format.
Style for the columns in a table or a view will be saved in content.xml inside the database file: <style:style style:name="co1" style:family="table-column" style:data-style-name="N20036"/><style:style style:name="ce1" style:family="table-cell"><style:paragraph-properties fo:text-align="start"/></style:style><number:date-style style:name="N20036" number:language="en" number:country="AU" number:automatic-order="true"><number:day number:style="long"/><number:text>/</number:text><number:month number:style="long"/><number:text>/</number:text><number:year number:style="long"/></number:date-style> See special: number:year number:style="long". I have tested this one with Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Same formatting after killing LO with an opened database and internal HSQLDB. So I couldn't confirm the buggy behavior. To prevent for loosing formats forms are the better way to input data than tables or queries (which won't save any format).
Hi Robert, Thanks for trying to replicate this problem. I think there must be something else going on with the date formats. If they were just stored in the "content.xml inside the database file" then they would be OK again after I restore the database file (.odb).
Could you attach the database here if the buggy behavior still happens? Not: There should be no personal data in the file, so first copy the file and delete the data in the copied file. Input some dummy value to see the format for date.
Created attachment 193960 [details] Test database as saved before power turned off Note before I turned off computer power, This file had all table dates in DD/MM/YYY format. Now, after the crash, when I open this file they all appear in DD/MM/YY format.
Created attachment 193961 [details] File after power turned off but before recovered
Created attachment 193962 [details] File after recovered
Hi Robert, I have attached 3 copies of my database with all rows removed from tables (except SystemParam which I don't care about). Note that before I turned the power off/on, all dates were in DD/MM/YYYY format. After the power cycling, not all tables have had their date format changed. The following tables have dates: BankTran,CPI,Dividends,PortfolioWorth, Price History, Shares & SystemParam. Only the following tables have had the date format changed to DD/MM/YY this time: CPI, PortfolioWorth, PriceHistory. In the past, previous crashes have caused dates in all tables to be incorrect. I'm pretty sure all tables have been affected at some stage, but my recent crashes have shown that not all tables are affected by every crash.
Something I haven't mentioned previously, is that after a date field has been unwantedly changed to DD/MM/YY, when I edit the table and click on "Format Field" for the bad date field, it shows as Category: Number, Format: General when it should be Category: Date, Format: 31/12/1999.
(In reply to Chris Good from comment #8) > Something I haven't mentioned previously, is that after a date field has > been unwantedly changed to DD/MM/YY, when I edit the table and click on > "Format Field" for the bad date field, it shows as Category: Number, Format: > General when it should be Category: Date, Format: 31/12/1999. Number format seems to be the default here for all fields as I could see in content.xml. I could reproduce the behavior if I open the table, for example "CPI" in your database, change the number format and don't save the Base file. If I save the Base file and kill LO the number format will appear as expected (DD/MM/YYYY). One hint, which has nothing to do with this bug: You are running a internal HSQLDB without any macro, which saves the file automatically. Seems data in this database aren't data for only testing and playing… Hope you have solved this security problem by any other app of your system.
Hi Robert, I am very careful to save any changes to forms/macros/tables, then also save the database, very regularly. Thanks for you comment about using a macro to save the file automatically. I hadn't really thought about that much yet. I do often save, close, then manually copy the .odb to a cloud backed up folder, then date and time stamp the filename. I have found some good info in https://ask.libreoffice.org/t/is-there-a-way-to-automatically-save-a-database/46905) which also refers to https://wiki.documentfoundation.org/Documentation/Publications#LibreOffice_Base_Handbook (Chapter 9 Macros → Securing you database) I have recently changed from an embedded database to an external HSQL 1.8 DB using Villeroy's Python macro (https://forum.openoffice.org/en/forum/viewtopic.php?f=21&t=86071), because I need to separate the data from the code so I can provide support for my system to some-one else. I decided to stay with external HSQLDB 1.8 for the moment instead of go to FireBird because of the problems with dates and also becuase Firebird does not support SPACE() which I use to simulate multi column comboboxes. I shall ponder further. I will probably end up modifying my java backup utility (https://github.com/goodvibes2/BackupGnuCashWin) which automates backing up multiple files to an encrypted datetime stamped file in a cloud folder using 7-Zip, to also handle my Base app. I'm also going to turn on Tools,Options,Load/Save - General, "Mark Save AutoRecovery information every 10 minutes" but I guess this won't help with this date format problem which presumably will be fixed now that my data is in an external database.