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 |
Cc: |
Description (last modified by )
Hello,
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 , 13 years ago
Description: | modified (diff) |
---|---|
Keywords: | numeric added; numeroc removed |
comment:2 by , 11 years ago
Owner: | changed from | to
---|
comment:3 by , 11 years ago
comment:4 by , 11 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.