Publishing Process is Looking for Parcel Fabric as own Table

[jcarlson]

I just updated to Enterprise 10.9 and Pro 2.8. Because of some previous database issues, I have been stuck at Parcel Fabric version 2, so I've been looking forward to this upgrade for a long time.

Imagine my disappointment, then, that the only thing that went wrong was re-publishing the fabric itself. I am publishing the service exactly as I always have, but it consistently fails, giving me the following message:

Failed to create the service.: Updating the server connection string for layer kendall_pf failed. Attempted connection string was [CONNECTION STRING]. Table name is kcgis.sdo.kendall_pf. Please verify the data exists on the server.

That's ERROR 001487, for reference.

I can see the 'kendall_pf' object (that's the Parcel Fabric) in the Catalog, and I see a corresponding entry in the sde.gdb_items table, but it isn't a table itself. Unless something has gone wrong in my parcel fabric?

I've tried re-registering the datasource and publishing with various settings, but it's consistently failing at this point. Any ideas?

[jcarlson · Accepted solution]

I looked around at various other posts about ERROR 001487, and the solutions seemed to range pretty wildly. I ended up doing a series of things, though I can't say for certain which step was the crucial one in solving this.

1. Rolled back my SDE to an earlier state, prior to upgrading.
2. Connected to the SDE using Pro 2.7 instead of 2.8.
3. Attempted upgrading the v2 Parcel Fabric -> ERROR 999999, my favorite
4. Created a brand new SDE
5. Used Copy Parcels to clone the fabric into the new SDE.
6. Attempted upgrading that v2 Parcel Fabric -> Success!
7. Attempted publishing that v4 Parcel Fabric as a service -> Success!

If I could do it over again, I suppose I'd try to just do steps 4-7 without the initial rollback, but ah well. As long as the service is up and running in time for next week's parcel splits, I'm not going to lose sleep over it. Perhaps someone with more knowledge about this could put in their two cents.

[AmirBar-Maor]

Hi Josh,

It's good to know your persistence paid off but I can;t left to wonder what the issue was.

The upgrade process requires latest geodatbase version, and since it was successful we can eliminate that as the reason.

As you also figured out, it seems to be something to do with the connection between the server to the datastore. Maybe a server cache was the issue.

I don't know if you tried to "refresh" the server by restarting the service or rebooting the server machine.

Good to know it works out.

Amir

[jcarlson]

Well, now that you mention it, I actually don't have the latest geodatabase. I'd attempted to upgrade the geodatabase initially after the upgrade, but Pro 2.8 wanted a newer st_geometry.dll than what shipped with the Server 10.9 install. Perhaps that was part of the difference?

I knew that v4 initially came out with 2.7, so that's why I rolled back and did the upgrades from 2.7 instead.