1

There are a few of us encountering "Memory allocation" errors when using ogr2ogr to import spatial (shp/gpx) data into a MSSQLSpatial databse. According to this post: Writing shapefile to SQL Server database with ogr2ogr Error the problem is due to using the latest version of the gdal libraries. The "answer" is to use a previous version, but I find this unacceptable for a number of reasons not the least of which is that an OSGeo4W installer will not enable you to install the 1.x version required and therefore it seems that its no longer possible to install older versions.

Im using gdal 1.11.2 with native SQL 11 driver successfully; however, 2.1.0 fails with same SQL driver.

Has anybody successfully had this work? What are the parameter/driver changes required to get this to work?

Improve this question
4
  • 1
    There are various compiled versions of GDAL/OGR at gisinternals.com.
    – klewis
    Commented Oct 13, 2016 at 21:22
  • Thanks but this is not a useful solution as I stated in my post. I'm after parameter /environment changes required to get thus to work with the latest version.
    – Chris Schulz
    Commented Oct 15, 2016 at 20:02
  • I was able to import (ogr2ogr) a Shapefile into MSQL Express 2014, native client 2012 using Gdal 2.2.0 dev from this release-1800-gdal-mapserver.zip, gisinternals.
    – klewis
    Commented Oct 17, 2016 at 15:36
  • You might disable bulk loading, MSSQLSPATIAL_USE_BCP=False. It is now enabled by default. Per this blog.gisinternals.com/2016_05_01_archive.html.
    – klewis
    Commented Oct 17, 2016 at 15:50

1 Answer 1

Reset to default
1

I haven't found a way to make it work with the latest and greatest GDAL (as of this writing). It's a bummer because I think they tried to improve it because of the hideous speed (I see ~4 records a second, and I have roughly 15,000,000 to go) so they tried to get BCP into the mix. Maybe it works for some, but not for me.

I'm using the older version which is really slow; but there's not much choice at the moment.

The only thing helpful I've found is that I actually get a massive performance bump (~100x speed) if I target my local SQL Server rather than the remote (where I really want the data to go).

My current plan is to OGR2OGR shape-> local SQL Server for my ~15,000,000 rows, then use SSIS to get the data to its final destination. I'm assuming that the SSIS import/export tools will use the hyper-optimized SQL Native Client and make the transfer as fast as it can possibly go.

Not the end of the world (to me).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.