https://bugs.documentfoundation.org/show_bug.cgi?id=146502
--- Comment #6 from Paul Ward <[email protected]> --- Alex, I created a small database with some dates and saw one reset of the display format, but I cannot tell how to reproduce it so there is no point in sending it. I have, however, found a workaround that solves both of my problems. In each table with a column holding a date I replaced the column with two columns based on function. The first new column is a string (CHAR(8)), which can hold and display a date in my desired format, YYYY-MM-DD. The second new column is computed by casting the string to a date. The user can add or change only the string field and never directly sees the computed date field. Since the user never sees the computed fields I do not care whether their display format changes. The computed column is not strictly necessary, I suppose, but having it reduces the number of implicit conversions from string to date in the views and forms that either sort or compare dates. To ensure the string input is in the correct format I defined a domain that performs a preliminary validity check on the input. Having the date represented as a string also avoids the limitation of the year 1600 imposed on date fields by the forms creator. My hunch (based on no knowledge of the interplay between LO and Firebird) is that it is Firebird that is changing the format--probably in some sort of cleanup procedure that is triggered by the amount or type of activity in the database. I consider this bug report resolved. -- You are receiving this mail because: You are the assignee for the bug.
