ogr2ogr v3.5.1 bcp import MSSQL not importing correctly

[domiSchenk]

Expected behavior and actual behavior.

I expect that the import from shape/geopackage works correctly.

Currently, it imports a random number of rows [from 0 - x of batch size] (the last test I did was 7000 of 43k rows) except for one row all were null.

Steps to reproduce the problem.

For setting up my environment I followed this: https://gis.stackexchange.com/questions/407711/gdal-ogr2ogr-into-sql-server-bulk-insert-bcp-not-working/408384#408384?s=799fb55248ae4a9e85f04bb8647ec3d9

the command i use is as follow:

ogr2ogr -f "MSSQLSpatial" "MSSQL:server={server};database={db};uid={user};pwd={pw}" 
  -lco SCHEMA=import  
  -nln bwe_ag_4  
  "C:\Users\dos\Downloads\lwb_bewirtschaftungseinheit_lv95 (1)\geopackage\lwb_bewirtschaftungseinheit_lv95.gpkg" 
  -lco GEOMETRY_NAME=geom 
  -lco precision=NO 
  --config MSSQLSPATIAL_USE_BCP TRUE  
  -lco UPLOAD_GEOM_FORMAT=wkb 
  -lco GEOMETRY_NAME=geom 
  -a_srs "EPSG:2056" 
  -overwrite 
  -progress 
  -lco OVERWRITE=YES 
  --debug on
  bewirtschaftungseinheit

and the debug output is:

GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\gdal_BAG.dll using GDALRegister_BAG.
GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\gdal_ECW_JP2ECW.dll using GDALRegister_ECW_JP2ECW.
GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\gdal_FITS.dll using GDALRegister_FITS.
GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\gdal_HDF4.dll using GDALRegister_HDF4.
GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\gdal_HDF4Image.dll using GDALRegister_HDF4Image.
GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\gdal_HDF5.dll using GDALRegister_HDF5.
GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\gdal_HDF5Image.dll using GDALRegister_HDF5Image.
GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\gdal_KEA.dll using GDALRegister_KEA.
GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\gdal_netCDF.dll using GDALRegister_netCDF.
GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\gdal_PDF.dll using GDALRegister_PDF.
GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\ogr_AmigoCloud.dll using RegisterOGRAmigoCloud.
GDAL: Auto register C:\_Tools\gdal\bin\gdal\plugins\ogr_MSSQLSpatial.dll using RegisterOGRMSSQLSpatial.
GPKG: GeoPackage v1.2.0
GDAL: GDALOpen(C:\Users\dos\Downloads\lwb_bewirtschaftungseinheit_lv95 (1)\geopackage\lwb_bewirtschaftungseinheit_lv95.gpkg, this=000001A4115463D0) succeeds as GPKG.
MSSQLSpatial: Use COPY/BCP: 1
ODBC: SQLDriverConnect(DRIVER={SQL Server Native Client 11.0};server={server};database={db};uid={user};pwd={pw})
GDAL: GDALOpen(MSSQL:server={server};database={db};uid={user};pwd={pw}, this=000001A4115A0370) succeeds as MSSQLSpatial.
GDALVectorTranslate: Using FID=fid and -preserve_fid
MSSQLSpatial: DeleteLayer(bwe_ag_4)
OGR_MSSQLSpatial: Using column fid as FID for table import.bwe_ag_4.
GPKG: ResetStatement(SELECT m."fid", m."wkb_geometry", m."t_id", m."bezugsjahr", m."ist_definitiv", m."code_bearbeitungsstatus", m."name_bearbeitungsstatus_de", m."name_bearbeitungsstatus_fr", m."name_bearbeitungsstatus_it", m."beschr_bearbeitungsstatus_de", m."beschr_bearbeitungsstatus_fr", m."beschr_bearbeitungsstatus_it", m."betriebsnummer", m."ps_nr", m."gemeinde", m."av_parzelle", m."zone_ausland_de", m."zone_ausland_fr", m."zone_ausland_it", m."identifikator_be", m."flaeche_m2", m."kanton" FROM "bewirtschaftungseinheit" m)
OGR_MSSQLSpatial: Using column fid as FID for table import.bwe_ag_4.
0

it does not matter if I use -lco precision=NO or -lco UPLOAD_GEOM_FORMAT=wk[b/t] also, it does not work when I omit the nln parameter

Operating system

Win 10 Pro, 64 bit

GDAL version and provenance

GDAL version v3.5.1 from GIS internals standalone zip

[domiSchenk]

if it helps i have following error in my Event Viewer:

Faulting application name: ogr2ogr.exe, version: 0.0.0.0, time stamp: 0x62dbc498
Faulting module name: ntdll.dll, version: 10.0.19041.1806, time stamp: 0x1000a5b9
Exception code: 0xc0000374
Fault offset: 0x00000000000ff609
Faulting process id: 0xcc30
Faulting application start time: 0x01d8c1d20a58fde7
Faulting application path: C:\_TOOLS\GDAL\BIN\GDAL\APPS\ogr2ogr.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 419b5858-f07f-46ec-826e-cec26b7b80ac
Faulting package full name: 
Faulting package-relative application ID: 

and the full command im using: ogr2ogr -f "MSSQLSpatial" "MSSQL:server=localhost;driver=SQL Server Native Client 11.0;database=dos;uid=sa;pwd=<YourStrong!Passw0rd>" -lco SCHEMA=import -nln t1 "C:\_GIS_DATA\_Shape\lwb_bewirtschaftungseinheit_intern\AI.shp" -lco GEOMETRY_NAME=geom -lco precision=NO --config MSSQLSPATIAL_USE_BCP TRUE -a_srs "EPSG:2056" -fieldTypeToString Integer,Integer64 -overwrite -progress -lco OVERWRITE=YES --debug on

the error does happen with geopackage and shape (but shape loads some features and geopackage not)

[lupynos]

I have exactly the same issue here. It's working as expected on older version GDAL 3.4.3. Starting with 3.5.x it is this error stated above.

(I can test anytime, please let me know. Thank you very much for support, GDAL is great tool.)

[aborremans]

I am also experiencing this same problem when importing shapefiles using gdal into MSSQL. When setting MSSQLSPATIAL_USE_BCP = FALSE, everything imports just fine, but imports much much slower. When setting MSSQLSPATIAL_USE_BCP = TRUE, records are generated for each row, but only the first row is populated with data.

Below is the command that I am running:

ogr2ogr -overwrite -f "MSSQLSpatial" "MSSQL:server=xxxxx.database.windows.net;database=dbName;UID=userName;PWD=password;trusted_connection=no;encrypt=yes;driver={ODBC Driver 18 for SQL Server}" C:/Path/To/Shapefile.shp -t_srs "EPSG:4326" -nln $newTableName -lco "PRECISION=NO" -lco "GEOM_TYPE=geometry" -lco "GEOMETRY_NAME=Geometry" -makevalid -progress --config MSSQLSPATIAL_USE_BCP TRUE

[elpaso]

I believe that this issue is fixed by https://github.com/OSGeo/gdal/pull/7792 , I wasn't sure at the beginning because it wasn't clear that it was crashing the application but the fact that only the first feature is imported is consistent with the crash that was happening right before the second feature was written.