[gdal-dev] MSSQLSpatial not using BCP to load

Hector muro muro.hector at gmail.com
Mon Jun 29 07:41:01 PDT 2020


Hi,

Cheers for that. I tried it, even specifying a "-gt 50000" for instance,
but still stuck with the single-transaction limit...

Any other suggestions?

On Mon, 29 Jun 2020 at 15:10, jratike80 <jukka.rahkonen at maanmittauslaitos.fi>
wrote:

> Hi,
>
> Don't use -skipfailures. It is only possible to skip errors one by one if
> transactions also contain just one row. It is even documented in the
> Performance hints in https://gdal.org/programs/ogr2ogr.html.
>
> -Jukka Rahkonen-
>
>
>
> hectormauer wrote
> > Hi,
> >
> > As a part of a project I need to load quite big geojsons into SQL Server
> > and I am using ogr2ogr to do so.
> >
> > Here is an example command I am using:
> >
> > ogr2ogr -f MSSQLSpatial
> > "MSSQL:server=xxx;database=xxx;UID=xxx;PWD=xxx;DRIVER={ODBC Driver 17 for
> > SQL Server}" -append --config SPATIAL_INDEX NO --config
> > MSSQLSPATIAL_USE_BCP TRUE --config MSSQLSPATIAL_BCP_SIZE 10000 --config
> > MSSQLSPATIAL_USE_GEOMETRY_COLUMNS NO -nln INM.nv_lv_ohline -nlt GEOMETRY
> > -t_srs EPSG:27700 -s_srs EPSG:4326 -skipfailures -splitlistfields
> > $DATA/data.json
> >
> > I found that it is very slow and I have been checking the SQL Server
> > profiler (as suggested already in this thread:
> > https://lists.osgeo.org/pipermail/gdal-dev/2018-May/048520.html) and I
> can
> > confirm that it is trying to insert every record one-by-one, hence the
> > slowness.
> >
> > What I can't get to understand is how to point gdal to my sql server
> > installation.
> >
> > SQL Server version: 2016
> > GDAL: 3.0.4
> >
> > Thanks and regards,
> >
> > Hector Muro
> >
> > _______________________________________________
> > gdal-dev mailing list
>
> > gdal-dev at .osgeo
>
> > 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
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200629/b2d422ff/attachment-0001.html>


More information about the gdal-dev mailing list