Created attachment 155472 [details] auto-field can be overwriten the title says it: -- open table in form-view -- enable table-view too -- pick a record for copying and drop it to the "+"-line -- manually override the preentered line/ID-number (cursor resides in auto-field) mh
@mhonline : which version of LO please ?
No repro for me with : Version: 6.3.1.2 Build ID: b79626edf0065ac373bd1df5c28bd630b4424273 Threads CPU : 4; OS : Mac OS X 10.15.1; UI Render : par défaut; VCL: osx; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded The autonum field gets recalculated automatically when I drop the new resultset onto the plus symbol and set to the correctly incremented value.
Created attachment 155864 [details] confusing table-view and numbering I retested behavior of auto-numbering in Form-View with table-view ON and found it confusing. 1. Auto-numbering delivers numbers, that can be overwriten in any view (5==>10 etc) whereas the vieworder is accordingly to the internal record-number. If this is ment as a feature (what it should not be), this needs to be stated somewhere 2. the table within the table-view seems to be not well connected to FB-table in the background. Attached you can find some experiments using the copy-function. the shown results are unpredictable/confusing - however, when closing and reopening the form-view, the results are now as expected. Since the neccessity of close/reopen is a no-go, this is a regression. m.
[Automated Action] NeedInfo-To-Unconfirmed
Please don't mix different bug descriptions here. Autovalue could be overwritten: I tested the same with Base and MariaDB. You could set new values for a autoincremented value. Same with the internal HSQLDB. Problem I see in Firebird: If you change the value it isn't recognized by the incremented value. It won't be start with the new value +1. So there will appear an error if the value will get a duplicate. The incremented value will be set to value + 1 after this error. Comment 3 is a new bug. I would prefer to close this one and open two new descriptions. One for the duplicate, which will appear sometimes and on for the autoincrement, which won't count the same as MariaDB and HSQLDB.
(In reply to Robert Großkopf from comment #5) > Comment 3 is a new bug. I would prefer to close this one and open two new > descriptions. One for the duplicate, which will appear sometimes and on for > the autoincrement, which won't count the same as MariaDB and HSQLDB. mhonline: can you please do what Robert requests? Thanks.
If needed, an auto value counter can be reset to continue from any arbitrary value of your choosing. This is done using an SQL statement. SET GENERATOR GeneratorName TO NewValue; Reference: Firebird Generator Guide: A guide on how and when to use generators in Firebird - 3.2.4. Setting a generator directly to a certain value (“Update”) URL: https://www.firebirdsql.org/file/documentation/html/en/firebirddocs/generatorguide/firebird-generator-guide.html#generatorguide-sqlsyntax-setvalue
Hello mhonline, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
while playing with a new build FD-ODB unter LO 7.2.2 (portable) I produced this crash: https://crashreport.libreoffice.org/stats/crash_details/52476ff1-de3b-4d1c-975e-3ee0ef701f80 rgds mh
Yes, opening a record in normal form- or tableview does not prevent the content of autoincrement-fields from being edited. not so good. But, when form is manually edited and ID-field is set to "Tabstop: no" and "dataentry: no", both views behave the same and can not be edited and AUTO works as expected as they were linked together. However, since there is a glitch in entering new records because of LO is filling fields "virtually" in form- and table-fields not with the new data but with data from the last but one record, this can only be seen, until form is closed and than reopend. As new entries can not be visually controlled, this complex issue can not be treated as solved. mh
Have removed me from CC. Too many behaviors of Base and databases are mixed here in one bug description. So nobody could confirm this bug.
mhonline: please define the single issue that you want this report be about. Then we can adjust the summary.
well, since FB can have one auto-numbering field per table only, it is up to developers decision, whether this need and will be protected in table- and form-view, or the problem shall be unsolved and the workaraound as stated above shall be the solution for the time being. Up to my believe, this need to be fixed, because FB does not have something like "recordnumbers", meaning to honour and make use of the order of entered data is impossible until now. Although the second issue with showing wrong data while having the right data in memory/background is somehow related to the autonumbering, I will put it into a new issue. mh
(In reply to mhonline from comment #14) > Up to my believe, this need to be fixed, because FB does not have > something like "recordnumbers", meaning to honour and make use of > the order of entered data is impossible until now. This is another feature you want: Try SELECT "ID", "Name", ROW_NUMBER() OVER (ORDER BY "ID") AS "Row" FROM "Table" This will show the row number (record number). You will never get the record number by an autovalue. There could be deleted rows and the number of records will differ. Too many different behaviors in this description. If one bug still exists please write a new description. I will set this one to RESOLVED and NOTABUG