Embedded firebird database. Discovered in Windows 10 August 2020 but have same issue in Linux Mint 20.1, June 2021. When editing a table, select row (field 'A'), right click on start of row, click on delete. The field has been deleted but the field name ('A')remains and the following field name('B')appears to have been deleted. If you click elsewhere in the window field name 'A' does changes to 'B'. (The field type behaves as expected - deleted immediately and replaced with following field type). I found this confusing as it appears that the next field down is being deleted, especially as in my case they were the same field types. (Posted on Ask LibreOffice and someone found out what was happening)
Have tested this: Edited a new table with 4 fields. Deleted the second field. Second field has gone and field name gets the right name. Then I created a table and saved it. Opened it for editing, not for input data. Deleted the second field. Same as above: Field name and field have been gone. So I couldn't see a buggy behavior here with OpenSUSE 15.2., 64bit rpm Linux, and LO 7.1.4.2. Its the same behavior here with LO 6.4.7.2 on the same machine.
Ok have double checked this again - you need to click on the field name before selecting row -so cursor is field name. Here is the question I asked - ignore my ranty post - look at the answer where they also managed to replicate the bug. https://ask.libreoffice.org/en/question/260406/is-it-me-base-firebird-weird-edit-table-behaviour/
(In reply to justforthis7 from comment #2) > Ok have double checked this again - you need to click on the field name > before selecting row -so cursor is field name. I could confirm this behavior: Edit a table. Set cursor in the field for field name you want to delete. Right click by mouse and delete the field. Seems the name hasn't been deleted, only the name of the next field has been gone. Click elsewhere and the name of next field will appear again. All tested with LO 7.1.4.2 on OpenSUSE 15.2 64bit rpm Linux.
Created attachment 172873 [details] Fieldname won't be refreshed directly, if cursor is part of the field and field will be deleted.
Seems to be an old bug: I could confirm it also with LO 6.1.5.2, which I have installed parallel here for testing. And the bug still appears in daily build of 11-06-2021 Have changed the version and set the Hardware to "All", because it appears under Windows and Linux.
Created attachment 172874 [details] screenshot of issue Hopefully this is a better illustration
Sorry - just seen your updates after uploading screen shot of issue Thanks
Bug still present in LO 7.4.2.3. I added bug 75354 to the See Also list, in case some underlying visual update mechanism for table editing is shared. Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: pt-PT (pt_PT); UI: en-US Calc: threaded
Dear justforthis7, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bu is still the same with Version: 24.8.3.1 (X86_64) / LibreOffice Community Build ID: 65412f067af443213e726c93f137ccc85c9a1e06 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