Bug report #16434
Can't split features in GeoPackage layer
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | Digitising | ||
Affected QGIS version: | 2.18.5 | Regression?: | No |
Operating System: | Linux | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 24343 |
Description
Expected behavior¶
When using the "Split Feature" tool on a feature in a GeoPackage layer, one of the new features keeps the fid of the old feature, and the other gets a new, unique fid.
Actual behavior¶
After splitting a feature and attempting to save, the operation fails with the message
Could not commit changes to layer seattle_censusblocks seattle_censusblocks MultiPolygon Errors: ERROR: 1 feature(s) not added. Provider errors: OGR error creating feature -2: failed to execute insert : UNIQUE constraint failed: seattle_censusblocks.fid
Cancelling the edits and leaving edit mode shows that one of the new features has been deleted, while the other new feature remains.
I've also tried editing the fid to be unique before saving, with mixed success.
History
#1 Updated by Giovanni Manghi over 7 years ago
- Easy fix? set to No
- Regression? set to No
#2 Updated by Jan Lippmann almost 7 years ago
i can confirm with qgis 2.18.15. i think the problem is the autodetection of the primary key (autogenerate), which not works
i think this issue should have high priority, because:
1. digitize a polygon
2. split this polygon
3. save edits -->error "...UNIQUE constraint failed.."
4. discard edit changes
5. some polygons are lost, with no undo possibility !!
i hope anybody can fix this in the next PR of 2.18.x
thanks
in actual master 2.99 this bug is gone, because the autodetection of the primary key works well.
#3 Updated by Harrissou Santanna almost 6 years ago
- Description updated (diff)
- Status changed from Open to Feedback
in actual master 2.99 this bug is gone, because the autodetection of the primary key works well.
With 2.18 no longer maintained and the bug gone not present in 3 (i extrapolate) does it mean that we can close this report?
#4 Updated by Nyall Dawson almost 6 years ago
- Resolution set to fixed/implemented
- Status changed from Feedback to Closed