Negative feature IDs, no updates possible

[qgib]

Author Name: Jeffrey Bostoen (Jeffrey Bostoen)
Original Redmine Issue: 20398
Affected QGIS version: 3.4.1
Redmine category:editing

---

I'm using data retrieved from a MySQL data source, using an x86 driver.
BIGINTs seem to internally be converted in some cases to negative values for ogc_fid.
Features get rendered, but it seems I'm unable to update any of the features with a negative ogc_fid

[qgib]

Author Name: Jeffrey Bostoen (Jeffrey Bostoen)

---

Actually tried a workaround with a GeoJSON file, but each time I edit it, it just creates another .tmp file and leaves the original file untouched ...

[debaser75]

This seems to be happening with geopackages on 3.4.2 as well. I imported OSM data to a geopackage. Some of the features were given a negative FID value. These negative values tend to be 'big' as well (e.g., -1984514722) even though there are only 319 features in this point layer. I can update an attribute value for any feature with a positive FID, but the edits don't persist when I edit a field on a feature that has a negative value.

It appears that negative FIDs are also causing this problem with PostGIS layers served via WFS, as documented here. So it seems like this may be an issue with QGIS and not the data sources.

[vesnikos]

yep, this seems to be the case for QGIS 3.12.2

[dingausmwald]

$id gives negative ids too. Qgis 3.14.15, geopackage, windows 10. Have to execute the $id command a second time after closing attribute table to get positive ids.

[andreasneumann]

As far as I know, the negative IDs are "normal" as long as you haven't saved your features to file or DB. Then they are changed to DB generated IDs. Unless you are in transaction mode, where you get the DB generated ids immediately. But transaction mode is only available for selected DBs, like PostgreSQL, Oracle and perhaps (not sure) SQL-Server.

[dingausmwald]

Yes, this was the case in earlier versions, at least ive seen this behaviour before. But now, with geopackage and 3.14.15, the negative ids stay even after save, after closing and opening the att table.

Whole steps where:
Create geopackage
create id field
copying some line features from one table to another (different table structure)
execute $id on all id fields (in att table)
save

• ids still -50 to -60 or something like that

[gioman]

Whole steps where:
Create geopackage
create id field
copying some line features from one table to another (different table structure)
execute $id on all id fields (in att table)
save

* ids still -50 to -60 or something like that

@dingausmwald can you attach sample data? thanks!

[Skipper-is]

I am having the same issue with version 3.22.10
I have attached the geopackage with the faulty layer. It isn't everything as it has sensitive data, but this is an example of what happens.
faultygeopackage.zip
I digitised a new feature, using snapping, around an existing feature, and initially it looked good. Pressed save, geometry is now null, FID is negative, and I now am unable to remove that feature from the layer to redigitise, or even see the feature (as geom is now null).
Has happened with a few features, and I've had to go in and do SQL "DELETE FROM" to get rid of them. Seems to mainly happen when snapping is used for me, like it is creating some invalid goemetry, but instead of telling me, it just corrupts everything. I'm using snapping to vertex, segment and area, with enable topological editing, snapping on intersection, and tracing on

[bpf800]

I have the same problem in QGIS 3.28.5. The layer is pure manual digitization except that at one point I transformed the project for QFieldCloud. Now one feature suddenly has fid '-62' and I cannot edit or delete it. Edits disappear as soon as I have typed them when I leave the field. Delete attempts give an error message, but not helpful:

Here a look at the attributes of this and similar features:

I think the main bug is that once a negative fid occurs, it should be possible to at least delete the feature. I am relatively new to QGIS and don't immediately know how to apply an SQL command like the previous commentor.

I have restarted QGIS and the laptop, and made and saved other changes to this layer after noticing the problem with one feature.

I don't know how this fid got there, but will provide some info:

• Even if I inadvertently typed into that autogenerate field, it would not have been a negative number as all my data are positive.

• Info about the layer:
  

• Form for the fid field -- I think it was the default:
  
  

The preview of '-62' as the default is strange. I have edited and added other features after looking at the wrong feature and this remains.

Any ideas? I can provide more info; the project is small and not secret.

[bpf800]

I tried to figure out @Skipper-is 's solution inside QGIS, found DB Manager, could enter select * from Kaesten where fid < 0 and see that I have 5 rows with this problem. However, delete from Kaesten where fid < 0 gives an error as it is interpreted as CREATE TEMP VIEW _tview AS delete from Kaesten where fid < 0: 1, because "kaesten" is shown as a virtual layer.

Am I missing a trick to edit the actual table from inside QGIS, or do I have to try to edit "kaesten.gpkg" with an external SQLite editor?

[bpf800]

(I did remove those rows with DB Browser for SQLite.)

I have found ways to reproduce the error, i.e., produce rows with negative fids that then become unmodifiable and undeletable:

• Add a feature (in my case a point). Do not save the layer yet.
• Open the attribute table and modify an attribute of this feature. Here I changed Column 'Details' for features with 'Nummer' 17 and 18:

• While other features added since last saving look like this:

The same happens if I click with the 'Move Feature' Tool on a feature that I added but did not save yet.