I have noticed since upgrading to ArcGIS 10.4, the SRID values of our feature classes have changed. All of our production feature classes use NAD 1983 (2011) Iowa State Plane North and are managed in SQL Server 2014 Standard using Geometry as the shape. The SRID for this spatial reference in 10.3 and prior is 103045. Starting at 10.4 the SRID is now 6463. Granted, our end users will never know the difference, and all the properties of the spatial reference are identical. However, I notice a huge difference when trying to run the same spatial queries within SQL Server that use multiple tables, most notably, for those feature classes that are created in 10.4, trying to apply the same spatial query doesn't work at all because the SRID value of the feature class created in 10.4 is different from those created in previous versions.
Below are examples trying to execute an intersect spatial query using a point feature class created in 10.3 (103045) and one created in 10.4 (6463) against an underlying polygon feature class created in 10.3 or prior (103045).
Is there any way of updating the SRID of a feature class without having to re-create the feature class in a current version? This wouldn't be too terrible except any relationships based on Esri system fields, for example, the GlobalID field when using attachments, would be very difficult to re-create because they would be re-generated for the new feature class.
One of the benefits of us maintaining our data in SQL Server is the ability to do these type of spatial queries within the database. By having multiple SRID values for the same coordinate system, we are losing the ability to run these types of queries.
Both feature classes (point shown below and underlying polygon) both have 103045 as SRID --- values are returned in the spatial query where features intersect
Same point feature class, however, created in 10.4 with SRID equal to 6463 and underlying polygon in 103045...no records are returned
Hopefully, someone from Esri can chime in on this...but I found the following workflow seems to work in changing the SRID stored for a feature class from one that was prior to 10.4 to one that is current. I'm sure if someone from Esri does chime in, they will mention that this workflow is not supported since you're monkeying around with back-end tables, but I don't see any other solution that doesn't involve re-creating the feature class, and loading data into it. And, while this may work for some, we use a fair amount of attachments and related tables which often use a GlobalID field as the parent key. These GlobalID values will get assigned new values when loading into a new feature class, so then you are stuck with trying to create a cross-reference between old and new features, personally, not an ideal scenario.
In our situation, most of our enterprise feature classes were created prior to 10.4 and have a SRID value of 103045. Starting at 10.4, the same coordinate system (NAD 1983 (2011) Iowa State Plane North) now has a SRID value of 6463. To our end users, they will likely never notice the difference, however, as an admin and someone that uses spatial queries within Sql Server for a fair amount of analysis and querying, I notice this as a big issue, because queries involving geometries within Sql Server only return values when the tables have the same SRID. So...it is very important for us to have our feature classes using the same SRID values across the board.
With that being said...here is the workflow I found that seems to work (I apologize for the length, but for anyone who may stumble across this when searching for a similar issue, I wanted to be as detailed as possible)...
This seems to have worked for me in migrating existing features from a previous SRID to the current SRID. This is pretty hacky in that you are messing with back-end tables, but this seems to prevent having to try and load features from one feature class to another. If any Esri folks want to chime in and tell me of a better way, I'm all ears ... or if this will cause some sort of catastrophe within our geodatabase, I'd appreciate that as well.