Hi, One workaround is to use -skipfailures and compare afterwards which IDs in the source data are not present in the target table. Skipfailures is forcing the transaction size into one row and it may be deadly slow if the output is GeoPackage because initializing/committing a transaction in SQLite is slow. With PostGIS as an outlut it is not as slow. A dry run into some some fast, not transactual format like GeoJSON could be used as some sort of test but that does not test the database constraints.
If you know your database and the contraints that you have you should be able to make quite nice tests by running SQL against the source data. But having a typeless SQLite as source can make it harder to write the SQL tests. That may even be a reason for your problems (field reserved for integers contains text etc.). I wonder why even the database engines would go on after finding the first error in the transaction. The whole transaction must be rollbacked in any case so why not to quit sooner rather than later? -Jukka Rahkonen- ghtmtt wrote > Hi all and happy new year! > > as suggested some days ago [0] I've set up a vrt file that I use to > export many tables from a gpkg to a PG. > > In the PG DB there are some constraints and with the vrt files all works > as expected: if an error (like a wrong value caught by the constraint) a > total rollback is made and nothing is written in the PG DB. > > But what if I've more than one single error on the gpkg? It seems (to > me) that when ogr2ogr identifies the first error the process is stopped. > > Is there a way to list ALL the (possible) errors of a single transaction > (like a dry run)? > > Cheers and thanks for any hint > > Matteo > > > [0] https://lists.osgeo.org/pipermail/gdal-dev/2020-December/053209.html > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
