QGIS » QGIS Application

When I close the file and re-open I get a message : WARNING CRS was undefined : defaulting to CRS EPSG:25832 - ETRS89 / UTM zone 32N

I'm experiencing the same bug... Suprisingly this doesn't happen if you save the layer to a new GeoPackage and then delete one column in the new GeoPackage.

The problem is also occurring with QGIS 2.18.26 (and QGIS is even crashing).

I've also checked on my Mac and it works perfectly, using the same GDAL version as the Windows version (2.3.2).

Exporting the whole GeoPackage with ogr2ogr using the following command also helps: ogr2ogr newgeopackage.gpkg skovkort.gpkg

I've first thought the problem was related to the GeoPackage version since I've only had problems with GeoPackages using version 1.0 (and not with version 1.2 which is now the default when using GDAL 2.3.2) but this doesn't seem to be the cause since the problem is also solved if I force ogr2ogr to export in version 1.0 (ogr2ogr newgeopackage.gpkg skovkort.gpkg -dsco VERSION=1.0).

It is fortunately possible to recover the data... Open the GeoPackage with an SQLite editor (e.g., https://sqlitebrowser.org) and look for the table with the removed column.

If your table/layer was called foo, then look for a table named foo_ogr_tmp. Rename this table using the original name (foo). QGIS will again be able to open the GeoPackage layer.

Lene Fischer wrote:

I have tried to replicate the error message but it does not appear any longer.

so you can't replicate the problem in a consistent manner?

I can easily replicate the problem - but not the error message. I think that it initially was a multiple session of deleting and creating fields that caused the OGR error message.

This is probably an upstream bug in OGR/GDAL or the underlying sqlite libraries.

I checked with a debugger on windows and QGIS is not doing anything strange: it calls the right OGR function with the right parameters, the call returns no errors but the table is completely removed from the DB (that's why QGIS asks for the CRS when re-opened).

You're right... I think I remember that SQLite was updated with QGIS 3.4.2.

Using OSGeo4W I downgraded SQLite from 3.25 to 3.17 and the bug is gone.

Alessandro Pasotti wrote:

@Jérôme, I can confirm: downgrading sqlite to 3.17 solved the issue, I'm not sure what you should do now, perhaps file a bug report for sqlite?

Or try 3.26.0-1

Unfortunately the bug is also occurring with this version.

OK, I believe this is the issue that was fixed per https://github.com/OSGeo/gdal/commit/556738b51b0b7b837544968199d359395a71e2ad in GDAL 2.4.0
The GeoPackage specification had an error in the formulation of a trigger, but before SQLite 3.25, SQLite was not sensitive to this error.
So GeoPackage generated with GDAL 2.4.0 should now work fine, but files generated by older versions will cause the issue.

Thanks for having a look at it.

Indeed this seeems to be the problem... If I correct the trigger in the "older" GeoPackages, then the issue doesn't occur. Would it be possible to correct this trigger automatically when the incorrect one is detected in a GeoPackage used in QGIS?