In the Table view, when adding a new record, the value of the field in the previous record is automatically duplicated in the new record and must be overwritten with the intended value for the new record. This is different from the behavior in version 4.x and all previous version that I have used, and is very undesirable.
Confirming on Version: 5.1.0.0.alpha1+ Build ID: 7f0161d88e3a496361e2209d31cc7e9ef42a677e Locale: fr-FR (fr.UTF-8) OSX 10.10.4 regression over 4432 It is : - really annoying ; - prone to produce erroneous data entry. Hoping that this isn't some "feature" that has been recently implemented.
Confirming on Version: 5.0.0.3rc Locale: en-US Win7 SP1 x64 Alex is correct, this is REALLY annoying! Corrupted 800+ rows. Thank goodness for backups!
David, Alex, Steve, if one of you could upload an example .odb, and give click-per-click instructions (for someone not familiar with Base), that would be nice, since it would allow QA to bibisect the issue (find the change that introduced the bug, or at least narrow it down to a small range). Or do the bibisect :) https://wiki.documentfoundation.org/QA/Bibisect
(In reply to Steve from comment #2) > Corrupted 800+ rows. Thank goodness for backups! Steve, your comment makes me think that maybe you hit a different issue / bug, since you seem to have corrupted *existing* data (*existing* rows), but David and Alex seem to be describing an issue only about *newly* *inserted* rows. Can you please confirm? If you have another bug, please describe it in a new bugzilla entry, and CC the rest of us into it. Thanks!
Created attachment 117369 [details] Try to insert new value - will show value of previous record first Could be this is a new feature. Open the attached database. Open the table for editing. Click with the mouse in the new row for "forename". There will be shown the content of the previous row. It will be marked and will be overwritable. Click with the mouse in the first row. Then click with the mouse in the new row for "forename". There will be shown the content of the first row. It will also be marked and overwritable. Don't know if this feature is a critical feature ...
(In reply to Lionel Elie Mamane from comment #4) > (In reply to Steve from comment #2) > > > Corrupted 800+ rows. Thank goodness for backups! > > Steve, your comment makes me think that maybe you hit a different issue / > bug, since you seem to have corrupted *existing* data (*existing* rows), but > David and Alex seem to be describing an issue only about *newly* *inserted* > rows. > > Can you please confirm? If you have another bug, please describe it in a new > bugzilla entry, and CC the rest of us into it. Thanks! Lionel, my apologies! Bad wording on my part. It does in fact only affect newly inserted rows. Behavior in my database is exactly as noted by Robert in Comment #5, and I can duplicate it with his sample database as well.
OK, reproduced. It is less serious than I thought. The "value from previous row" (which is from the last selected row, not the last row of the table) is prefilled, but it is *not* saved unless one actually edits it. The prefilling happens only on the field that has focus, not the whole row. But in my test, it happens also in existing rows, as soon as a field is NULL (empty), it happens in that field. It is not saved unless one edits it, even if one edits another field.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3b9e66fdcade5a222a9dc99ad74627473b1fd4e7 tdf#92725 FormattedField: when model value is NULL, force empty display string It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bcca7b95d60fadfbaf93b542c110e177e838db8a&h=libreoffice-5-0 tdf#92725 FormattedField: when model value is NULL, force empty display string It will be available in 5.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-5-0-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=07ce7182fc7115292aea8f5bd43f4f983c1eb1a3&h=libreoffice-5-0-0 tdf#92725 FormattedField: when model value is NULL, force empty display string It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.