Since upgrading our ArcGIS Server from 10.1 to 10.2.1 we have run in to a snag when trying to identify a feature that contains a double value, even if that value is not included in the map service. If the value is NULL it will identify fine. The same issue is also present in ArcCatalog but not in ArcMap. The underlying data resides in a ArcSDE 10.1 database on SQL Server 2008 Standard R2.
We have copied the data to a file geo-database and the identifying is fine, likewise if we change all double values to NULL in ArcSDE.
Has anyone else experienced this and if so, were you able to fix it and what did you do?
It turns out that we needed to update to the latest version of SQL Server Native Client on the ArcGIS Server. Once we updated this, the problem was solved.
So what is the behavior when you attempt to identify a feature where the DOUBLE field value is not NULL? Do you get an error or does nothing happen at all?
So what is the behavior when you attempt to identify a feature where the DOUBLE field value is not NULL? Do you get an error or does nothing happen at all?
When we identify a feature with a value in a double field it returns with "Nothing found", just like if you identify a blank area in a map. When the double value is NULL it identifies normally and returns all attributes that are set to display.
Are you performing the identify operation on a feature class, a spatial view, or a query layer? What is the backend spatial data type (e.g., SDEBINARY, ST_GEOMETRY)?
Are you performing the identify operation on a feature class, a spatial view, or a query layer? What is the backend spatial data type (e.g., SDEBINARY, ST_GEOMETRY)?
We are identifying a Feature Class inside an ArcSDE database. How can I check the backend spatial type?
Once you run this, look for the Layer Type in the output. I can't find anything listed online that describes your exact situation/behavior and this is beginning to sound more like a potential bug. The closest thing I could find is this, but it is a few software versions old and it does not involve the same circumstances as you described.
Once you run this, look for the Layer Type in the output. I can't find anything listed online that describes your exact situation/behavior and this is beginning to sound more like a potential bug. The closest thing I could find is this, but it is a few software versions old and it does not involve the same circumstances as you described.
Thanks, the Layer Type is In-Line Spatial Type. We have this issue with all shape types, e.g. points, lines and polygons.
On the backend, if the DOUBLE (ArcGIS data type) field within SQL Server is showing as NUMERIC, FLOAT, or DECIMAL (SQL Server data type) when you look at it through SQL Server Management Studio then the identify should be working based on what the SQL Server data types supported in ArcGIS help documentation provides. What are your precision and scale values set to for the field when you look at the feature class properties? On a side note, I am thinking you may want to consider opening a ticket with Esri support to discuss this issue.
On the backend, if the DOUBLE (ArcGIS data type) field within SQL Server is showing as NUMERIC, FLOAT, or DECIMAL (SQL Server data type) when you look at it through SQL Server Management Studio then the identify should be working based on what the SQL Server data types supported in ArcGIS help documentation provides. What are your precision and scale values set to for the field when you look at the feature class properties? On a side note, I am thinking you may want to consider opening a ticket with Esri support to discuss this issue.
In SQL Server the double fields show as numeric(38,8). These are the settings that we get for Precision(38) and Scale(8) if we don't define them when we create the field. We have also discovered that when we publish a feature service, any feature class with doubles will not display. We have logged it with Eagle Technology our ESRI distributor, but no solutions at this stage.
It turns out that we needed to update to the latest version of SQL Server Native Client on the ArcGIS Server. Once we updated this, the problem was solved.
