I normally open a new record and populate it with data. Then I either save, move to another record using the < > arrows (or a record number in the search box). or create another new record. With such an action the unique key number is generated and entered into the field. This does not occur now. The new record cannot be saved because the key field is perceived as empty. Reproducible: Always Steps to Reproduce: 1. Open data entry form 2. click on 'new record' + 3. enter some data 4. click 'Save Record' button 5. OR click on 'New Record' or the 'Go to previous record' < Actual Results: Warning: Record changing failed. You can correct data in this record or use "Cancel record changes" function. Primary key's field "hash" cannot be empty. SQL statement: UPDATE books SET Server result: 0 Expected Results: Record should be allocated next sequential key number Using postgresql 8.4 To work around 1. open new record, enter a couple of characters and then CLICK 'Cancel Record Changes' THEN EITHER 2. move one record back 3. move one record forward which will now be numbered OR 4. click 'Save Record' OR 5. click 'New Record'+ ie. a new key can only be allocated when saving a record which has been subjected to 'Cancel Record Changes'. Saving a freshly created empty unedited record will not generate the new key. various editing gymnastics are needed to enable this. Effectively you must ensure that the new record is numbered before entering in data.
In the penultimate line above: "Saving a freshly created empty unedited record will not generate the new key. various editing gymnastics are needed to enable this" add - neither will saving a freshly created record for which some fields have been completed" Working on this all day everyday at present my preferred method of handling this is to open a new record, type data into one field, Ctl+A, Ctl+X, Cancel Record Changes, Save Record, Ctl+V. This is the easiest workaround.
Confirmed, thanks Ian! It looks like a regression. Wouldn't a possible workaround be like this: 1. Click the "Go to last record" button ">|" 2. Click the "Go to next record" button ">" 3. Enter the new record's data. 4. Click the Save button or if you want to enter another record afterwards, click the "Go to next record" button ">". Both approaches save the record, while the latter acts as a Save+"Go to a new empty record" combined action. BTW, using the Next button to when multiple records have to be added is perhaps a good habit _regardless_ of existence of the reported bug.
Another note, the issue is common for table and form views.
75% done
Jaroslaw That works too. A good workaround. Ian On 2015-03-29 22:09, Jarosław Staniek wrote: > https://bugs.kde.org/show_bug.cgi?id=345210 > > Jarosław Staniek <staniek@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |ASSIGNED > CC| |staniek@kde.org > Ever confirmed|0 |1 > > --- Comment #2 from Jarosław Staniek <staniek@kde.org> --- > Confirmed, thanks Ian! It looks like a regression. > > Wouldn't a possible workaround be like this: > 1. Click the "Go to last record" button ">|" > 2. Click the "Go to next record" button ">" > 3. Enter the new record's data. > 4. Click the Save button or if you want to enter another record > afterwards, > click the "Go to next record" button ">". Both approaches save the > record, > while the latter acts as a Save+"Go to a new empty record" combined > action. > > BTW, using the Next button to when multiple records have to be added is > perhaps > a good habit _regardless_ of existence of the reported bug.
@Ian ready to test, can be obtained via the Download Diff button at https://git.reviewboard.kde.org/r/123226/
Git commit 0bc8d1f91cc81cc9767def9006a25955aee157a7 by Jaroslaw Staniek. Committed on 02/04/2015 at 19:27. Pushed by staniek into branch 'kexi-345210-staniek'. Fix logic for adding new records for Kexi tables and forms - recently we allow editing to start in a row different than the current row, for this we need to remember which row is being edited, not just if the current row is edited - the above is used by a feature that first starts editing a row (e.g. the last) and only after that moves the cursor (animations are possible this way) - fixed buffered changes in edited record, otherwise saving did not work properly - added sanity checks for cases when editing of a row is requested but editing of other row was not accepted/cancelled FIXED-IN:2.9.3 M +15 -10 kexi/plugins/forms/kexiformscrollview.cpp M +1 -1 kexi/plugins/forms/kexiformscrollview.h M +33 -21 kexi/widget/dataviewcommon/kexidataawareobjectiface.cpp M +7 -7 kexi/widget/dataviewcommon/kexidataawareobjectiface.h M +2 -2 kexi/widget/dataviewcommon/kexidataawareview.cpp M +24 -18 kexi/widget/tableview/KexiTableScrollArea.cpp M +1 -1 kexi/widget/tableview/KexiTableScrollAreaHeaderModel.cpp http://commits.kde.org/calligra/0bc8d1f91cc81cc9767def9006a25955aee157a7
Git commit 71d7aaa3412e07a8ef4083167410d60833c854d6 by Jaroslaw Staniek. Committed on 19/04/2015 at 22:16. Pushed by staniek into branch 'calligra/2.9'. Fix logic for adding new records for Kexi tables and forms - recently we allow editing to start in a row different than the current row, for this we need to remember which row is being edited, not just if the current row is edited - the above is used by a feature that first starts editing a row (e.g. the last) and only after that moves the cursor (animations are possible this way) - fixed buffered changes in edited record, otherwise saving did not work properly - added sanity checks for cases when editing of a row is requested but editing of other row was not accepted/cancelled FIXED-IN:2.9.3 M +15 -10 kexi/plugins/forms/kexiformscrollview.cpp M +1 -1 kexi/plugins/forms/kexiformscrollview.h M +33 -21 kexi/widget/dataviewcommon/kexidataawareobjectiface.cpp M +7 -7 kexi/widget/dataviewcommon/kexidataawareobjectiface.h M +2 -2 kexi/widget/dataviewcommon/kexidataawareview.cpp M +24 -18 kexi/widget/tableview/KexiTableScrollArea.cpp M +1 -1 kexi/widget/tableview/KexiTableScrollAreaHeaderModel.cpp http://commits.kde.org/calligra/71d7aaa3412e07a8ef4083167410d60833c854d6