<div dir="ltr"><div dir="auto">Hello Patrick,<div dir="auto"><br></div><div dir="auto">Yes, there are (were?) some glitches while working with geopackages. But a lot of fixes and improvements have been made in recent releases.</div><div dir="auto"><br></div><div dir="auto">I remember a thread in a mailing list about the fid annoyances, but I am not sure what was the decision.</div><div dir="auto"><br></div><div dir="auto">Regarding geopackage vs spatialite: remember that they are different beasts. Both are independent implementations on top o SQLite. Maybe a better route would have been to make spatialite a standard, instead of creating something new, but...</div><div dir="auto"><br></div><div dir="auto">What version of QGIS are you using?</div><div dir="auto">3.10.?</div><div dir="auto"><br></div><div dir="auto">Can you give it a try in more recent versions or in the nightly builds (current in development) to see if it helps</div><div dir="auto"><br></div><div>Best regards,</div><div><br></div><div>Alexandre Neto</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">A terça, 2/02/2021, 02:13, Patrick Dunford <<a href="mailto:enzedrailmaps@gmail.com" target="_blank">enzedrailmaps@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I recall going back someway we were sold this Geopackage idea being <br>
implemented into Qgis because it was going to be so much better than <br>
shape files that everyone has been using up to now. I bought into these <br>
ideas by converting shape files in most of my Qgis projects into <br>
Geopackage files.<br>
<br>
However there appear to be some serious bugs in Qgis' implementation of <br>
Geopackages as a file based system, and since SQlite has an impeccable <br>
reputation, it is a reasonable conclusion that there must be significant <br>
uncorrected bugs in the Qgis code that deals with file based Geopackages.<br>
<br>
Here are two examples:<br>
<br>
1. Changing the data table associated with a layer, specifically the <br>
operation of deleting columns, is almost 100% guaranteed to result in <br>
automatic deletion of 100% of the features in the layer when the layer <br>
is saved. I have seen this happen multiple times, whether in a layer <br>
with 92 features or one with half a million.<br>
<br>
2. Compared to shapefiles, Geopackages add an extra field called a fid <br>
which is a unique numerical value. For new records, this value is <br>
automatically generated. This requirement of uniqueness and the field <br>
apparently being unchangeable by the end user makes it impossible to <br>
paste features from another table if the values in the fid field for <br>
pasted features happen to coincide with existing entries in the table.<br>
<br>
These two examples are making me consider changing back to shapefiles in <br>
all my projects because shapefiles did not cause either of these two <br>
problems. Supposedly a shapefile is more prone to data corruption. This <br>
may be the case but as the code in Qgis that deals with shapefiles <br>
appears to be considerably more mature, these considerations have to be <br>
reasonably weighed against each other.<br>
<br>
Particularly in the case of issue 1, this appears to be a regression <br>
since I do not recall it being an issue on Qgis 2.18 or possibly earlier <br>
versions of Qgis 3. (I use the LTS edition of Qgis)<br>
<br>
_______________________________________________<br>
Qgis-user mailing list<br>
<a href="mailto:Qgis-user@lists.osgeo.org" rel="noreferrer" target="_blank">Qgis-user@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
</blockquote></div>