Note that there is a workaround for the problem as indicated in the bug description. I hope that this workaround can be used until the update is available. We're currently testing the fix, and working on publishing an updated patch for 10.3--it will be available as soon as possible. There will also be a 10.3.1 patch to follow that addresses this same problem. Apologies to all those affected.
I am aware of the workaround, and it does seem to be working although it is a pain. I just wanted to make folks aware of the issue - it took me quite a while to notice it was happening.
Thanks Jeff. Did you notice the problem prior to saving edits, or do you now have instances of control points stored in the database that have had the incorrect unit conversion already applied? If you (or anyone reading this) have a large number of instances of the wrong control points stored in the database as a result of this problem, there is a way that these can be repaired.
Since we know that the coordinates are getting a unit conversion applied, we can detect the control points that are well outside the proper extent, export them to a table (dropping some of the system fields), recalculate the X and Y fields by multiplying them by a scale factor, and then re-import them using the Control point Importer. Once it’s been determined that the process occurred correctly, then the control points that are in the wrong location can be deleted.
I’ve uploaded a toolbox to AGOL with a script for exporting the control.
Here are the steps to follow after downloading it:
If your original data is in US Feet then calculate as follows:
If your original data is in International Feet then calculate as follows:
I did save edits before I knew about the workaround. I was deleting the faulty control points and replacing them with new ones where they belong. Now that I have the data frame set to the meter equivalent of my coordinate system it's not a problem. When I enter a control point, I have to switch the data frame back to feet.