I have an otherwise working AGE environment, but I encounter this error when publishing some featureclasses through an otherwise-working registered data store, where it seems to be dependent solely upon the specific name given to the featureclass in the EGDB.
That is, certain names seem to be "publishable" while others are "unpublishable", and there doesn't appear to be any obvious reason for it. (e.g., they're not SQL reserved words or such) So, if I take an otherwise unpublishable layer with a "bad name" and simply rename it to a "good name", with no other changes, it then becomes publishable - and vice versa, and repeatable.
For example, I know from experimentation that a layer named "Parcels" will be publishable, while a layer named "Zoning" will not be publishable. Rename both of them to vice-versa and the problem follows the name. (many other known good/bad names, but again - no obvious pattern to them)
The server log has two relevant entries, the generic part:
ERROR 001487: Failed to update the published service with the server-side data location
and the detailed part with the connection info that failed to swizzle:
Failed to create the service.: Updating the server connection string for layer DummyAsZoning failed. Attempted connection string was <omitted> Table name is <instance>.<schema>.Zoning. Please verify the data exists on the server.
I omitted the connection details for privacy but they're known to be valid, AND the connection details are exactly the same as when it's renamed as Parcels (or other "good name") but publishes successfully.
Any ideas what might be causing this? Thanks!
Environment: AGE 10.8.1, AGPro 2.6.1, MSSQL 2019 (EGDB is 10.8.1)
More FYI, in case it helps anyone else: Esri Case #02650635
After some exploration and experimentation, the problem seems to be related to an upgrade of our EGDB to 10.8.1.
It was found that all of the unpublishable "bad names" had a similar history: Prior to the upgrade, another featureclass existed in another schema having the same name. For example, if the good copy was: database.Authoritative.Zoning, then there was also something like: database.Temporary.Zoning. So both same-named featureclasses were present during the upgrade, and subsequently appears to have led to some sort of internal "mix up" that caused trouble when resolving names.
The "fix" is to simply remove the non-authoritative copy, this will resolve the "bad name" conflict, and the authoritative version will again become publishable. (recreating a same-named featureclass in other schemas after the upgrade does not replicate the problem going forward - in only appears to occur if the same-name-different-schema situation existed during upgrade)