Description: Base consistently does NOT save changes, regardless of saving table information and then saving the database. There is no error message. There does not appear to be a failure until you reopen the database and ALL the changes are gone. Steps to Reproduce: 1.Create several tables 2.Add descriptions for data fields 3.Save the table changes 4.Save the database 5.Reopen the database Actual Results: Complete loss of changes to multiple tables, including switches (Autonumber) and descriptions of data fields. Expected Results: It consistently does NOT save changes, regardless of saving table information and then saving the database. Reproducible: Sometimes User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
@aermyr : ideally, we would need a sample database where the problems occur reproducibly, and clear, detailed descriptions of how to get this to happen, otherwise this report will never be able to be confirmed.
If the only problem is related to saving of the field descriptions, I believe that this has already been reported. For other unsaved changes, please indicate in separate bug reports, which changes you have made, and provide a sample test database.
There was bug 34988 that was closed due to insufficient information provided by the initial reporter, although his circumstances were specific in that he found he could not copy/paste previously created field definitions into a new field definition and have the description of the field saved.
For the autonumbering issue, please open a separate report and provide detailed steps of what it is you are doing.
Thanks for the reply Alex. Here's my problem... If I could reproduce the exact same situation and/or error reliably then I would have included the information. I said arbitrarily because it appears to be arbitrary. I can save the database, close it, reopen it, and get apparently random changes where some tables that had an autonumber field turned on would now have it turned off. There's no way to tell without reopening every single table, which I did more than once to verify that it was indeed happening with no pattern that I could discern. In every case two or more tables would have the autonumber switch wrong AND on some tables the descriptions that had been entered previously were simply gone. I already ran into the copy/paste problem, but that was already reported so I didn't mention it. You can consider it confirmed if you wish. Given the situation, I didn't think previous bug reports applied to the situation, thus the new submit. It has happened with the same database on two different computers (Win7 and Win8.1). It has happened multiple times on each. I can't reproduce the same errors in the same tables every time, or I would have said so. However, every single time I save and close and go back in, some of the tables will be wrong. It is either resetting/changing the entries (autonumber), not saving the entries (descriptions or autonumber possibly), or deleting the entries (description). Sometimes it is recent changes and sometimes it happens in tables that were changed several saves previously. So, quite frankly, I assumed the problems were related. My error. My first guess would be that there is a serious memory problem. Second guess is that there is a hard limit on the amount of metainformation like table element descriptive entries and when that is reached, it just starts doing random crap. Or some combination. Either way, for me it isn't usable so I quit using it. I could live with retyping rather than copy/paste, but losing and/or changing information that was saved with no error message is a whole different problem.
@aermyr : thanks for your feedback. Your idea about metadata storage limits might not be too far off the mark. I don't know what the limit on this kind of metadata is, but it probably isn't limitless, and perhaps there is indeed a bug in committing a large amount of such information to the database file. However, I consider the description information loss and the autonumber setting to be different bugs. They should therefore be filed under separate reports. It would help us if you could provide a sample ODB file where the problem occurs - obivously, this is a public web site, so you would need to scrub any confidential or personal information from it, or else provide a sample ODB with random data that we could use to test. My second request would be that you indicate whether, when you say that autonumbering is lost, do you mean that the UI in table design mode displays AUTOVALUE=FALSE, or do you really mean that entering data in table data entry mode refuses to increment a new tuple with the correct number ? What I'm trying to ascertain is whether the database DDL is rewritten when you encounter the problem, and saved to the underlying database so that autonumbering is effectively lost, or whether it is merely a confusing (and buggy) UI artefact, whereas the underlying database schema still maintains autonumbering correctly. In all of this, I am assuming that you are using the native embedded hsqldb 1.8.0 engine that is currently the default database engine for LibreOffice. If you are using another db engine as the backend, please specify which one, and how you are connecting to it (driver type, version number, db engine version).
I won't be able to get back to this until after the first of the year, but I will get back to it. So, briefly 1) It's possible it is the memory on my machine, but I'm running 16GB. 2) I am using the straight Base /hsqldb that comes with LibreOffice. Just thought of something else though... I have OpenOffice installed as well, if that could be part of the problem? Sorry, haven't used it in a while and forgot about it. 3) I am referring to the AUTONUMBER switch in table creation mode, not data entry mode. As far as I can tell, it doesn't refuse to increment during data entry unless it happens to be one of the tables where the autonumber was changed back to false. Even then, it just doesn't autonumber at all. 4) I'm wordy so I have lots of description metadata. It will take me a little while to pull the data out, but I'll get it to you. 5) I'll input a new autonumber bug after new year's. Enjoy the holiday season!
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20170628
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20170727