Hi Matthias
I have seen this type of error message comes up when trying to open a
geopackage from a 3.x project in 2.18
No data corruption in the original layer as far as I can tell.
On 04/08/18 01:59, Matthias Kuhn wrote:
Hi everyone,
I recently gave a course where geopackages were used
>> Executing PRAGMA foreign_keys = ON
This is also done for Spatialite in the SpatialiteProvider, so this is not
a general GeoPackage issue.
The need to keep this on is important, since the TRIGGERS enforces the
'sanity' of the data (such as same srid and geometry-type rules).
Also the
On jeudi 9 août 2018 07:07:10 CEST Matthias Kuhn wrote:
> Thanks Even,
>
> Executing PRAGMA foreign_keys = ON sounds interesting, one thing we'll
> then need to check on the relation editing end is that we make proper
> use of deferred foreign key constraints.
>
> What do you think about the way
Thanks Even,
Executing PRAGMA foreign_keys = ON sounds interesting, one thing we'll
then need to check on the relation editing end is that we make proper
use of deferred foreign key constraints.
What do you think about the way to go concerning handling broken files?
The current situation is that
Matthias,
Looking a bit at this, I see from sqlite doc that foreign key constraints are
only enforced if the user runs
PRAGMA foreign_keys = ON
which OGR does no activate by default, hence the easyness to break them.
This can be enabled by defining the configuration option/environment
Hi everyone,
I recently gave a course where geopackages were used as datasets. Those
geopackages had foreign key constraints (among others) activated. While
editing those files, at least on one machine, someone managed to get it
into a "corrupted" state (layer disappeared). Trying to load this
