Opened 13 years ago

Closed 11 years ago

#3920 closed defect (wontfix)

OGR Esri-Shapefile ==> SQLServer Spatial Conversion, num. overflow

Reported by: kk Owned by: tamas
Priority: high Milestone:
Component: OGR_SF Version: 1.6.0
Severity: major Keywords: OGR SQLServer Spatial numeric overflow

Description (last modified by KK)


if OGR creates a new SQLServer table, it derives SQLServer datatypes from dbase datatypes. For numeric columns, it chooses either NUMERIC(x, 0) or NUMERIC(x,y). In practise, depending on the different kinds of shapefiles, this can lead to a numeric overflow indicated by the SQLServer driver. In many cases, OGR creates the target table and crashes while inserting the first row.

A good solution would be if OGR chooses INT instead of NUMERIC(x,0) and FLOAT instead of NUMERIC(x,y). If anybody prefers NUMERIC() datatypes, he can create the target table before starting OGR and runs OGR in -append mode.

Kind Regards,

Klaus Kuehne

Leibniz Institute for Applied Geophysics

Hannover, Germany

Change History (4)

comment:1 by KK, 13 years ago

Description: modified (diff)
Keywords: numeric added; numeroc removed

comment:2 by tamas, 11 years ago

Owner: changed from warmerdam to tamas

comment:3 by tamas, 11 years ago

This behaviour is controlled by a layer creation option 'PRECISION'. When using ogr2ogr you can use -lco PRECISION=FALSE to have int and float columns generated instead of numeric columns.

comment:4 by tamas, 11 years ago

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.