Yet another snag in our migration from 10.1 SP1 to 10.3.
We have upgraded our Server, web adaptor, desktop and geodatabase to 10.3 and all seems to be working as expected, except that our print command from our customized server site stopped working. By stop working I mean it was no longer filtering buffers that were beyond a certain radius. our exportwebmap GP takes the point and associated buffers and prints them to a pdf but eliminates all radii that exceed 1/2 mile using the Shape.STLength field.
In our config.js file "PrintMapBufferLenghtLimit: 5060, //in meters, this is just over the circumference of the 0.5 mile ring"
So all the radii rings were being printed and we started digging.
Looking at the buffer feature in our SQL enterprise GDB via Catalog, this field is VISIBLE and the buffers all draw and respond appropriately, so clearly it's there.
Looking at the buffer feature in our SQL enterprise GDB via SSMS, this field is NOT VISIBLE, which is most likely why our code is not able to filter properly. Within SSMS if you expand the table and expand columns, it is missing, along with the Shape.STArea() field.....wtf?
EDIT: All polygon features in our database are missing these two fields in SSMS.
Any idea out there? How do we get these fields back into SSMS and why did they go missing in SSMS but not catalog or desktop?
Solved! Go to Solution.
Collin,
What you are seeing I think is normal. Below is a screen shot showing the same feature class as seen from Management Studio on the left and ArcCatalog on the right. I think STArea and STLenght are virtual fields as presented by ArcGIS. So I think that's a red herring. Have you looked at the Shape.STLength values in ArcMap to see if they are really inside the 1/2 mile filter?
How did you do the upgrade? Is it possible that your feature classes are now using SDEBinary instead of the SQL Spatial datatype. In ArcCatalog what does it say under Properties | General Tab | Storage?
Hi Randy,
Once I read this, I was sure it was the case, but after reviewing the storage settings I no longer think this.
The database was upgraded by way of Right Click on DB in catalog > General tab > Upgrade Geodatabase under the upgrade status area at the bottom.
Storage: High Precision using Geometry spatial type (SRID 102008)
Collin,
What you are seeing I think is normal. Below is a screen shot showing the same feature class as seen from Management Studio on the left and ArcCatalog on the right. I think STArea and STLenght are virtual fields as presented by ArcGIS. So I think that's a red herring. Have you looked at the Shape.STLength values in ArcMap to see if they are really inside the 1/2 mile filter?
Unfortunately, I can't seem to find the documentation I want to reference right now, so I will have to get by with some examples. https://community.esri.com/migrated-users/4406 is on the right track, especially about the filter problem not being related to what you are, or aren't, seeing in SSMS.
The Shape.STArea() and Shape.STLength() aren't missing in SSMS because they are a derived field in ArcGIS Desktop. The Feature classes in a geodatabase in SQL Server documentation doesn't explicitly state this; unfortunately, but it does imply it by not showing STArea() or STLength() on the diagram of geometry storage in SQL Server. Additionally, the names of those fields gives a hint they are derived because the TSQL syntax for generating the area of a geometry is geometry.STArea() . If you used SDEBINARY instead of GEOMETRY for storage, you would notice the names of the fields change to Shape.area and Shape.len because "area" and "len" are columns in the feature table (F<layer_id>) for storing geometric shapes in binary.
If you have an unversioned feature class, you can emulate in SSMS the table structure you see in ArcGIS Desktop fairly easily.
The top window is the SQL to emulate the table in the bottom window, and the middle and bottom windows show the values. Something similar could be done with versioned data, but you would have to build off of a versioned view (_evw) instead of the base table.
Randy, Joshua - Thank you. I wish I could mark you both as correct.
I went back and did more thorough research and realized these fields didn't disappear at all. You guys are spot on. I understand what I am seeing now. I have shared this with the developer and we are all on the same page now.
What I don't understand is why the filter is not working. When we send the JSON exportwebmap parameters without the Shape.STLength() in the definition expression the print works. Include this and we get our failure. All values check out in arcmap too.... I'm hoping the developer digging through the code a bit more will reveal the problem.
But I think that's for a new thread.
Cheers,
Go ahead and mark Randy .'s response as the answer. He responded first and identified the issue, I just elaborated on it.