Server publishing errors 001487 and 001369

[JayHodny]

I have  reviewed several other posts on this topic, but I cannot seem to resolve this issue.  I was attempting to publish a polygon feature class, in ArcMap to our ArcGIS Server, which we have done many times with other feature classes (screen shot below).  I registered the data connection which removed the publishing errors and warnings.  I believe I have done that correctly (though this step(s) is confusing).  I continue to get the error.  I scrapped the MXD, database connection, data store record, etc., and started completely over.  Same result.  I tried publishing another feature class and was successful in having it publish on Server, which suggests there is an issue with the feature class(?).  The Server logs are asking to 'verify the data exists on the server.'  I am assuming given the feature class displays correctly and has an attribute table, then the data exist.  This service is to be editable on a daughter version in sde and going into a simple app so zoning on parcels can be updated easily.  I would rec and post the edits to sde after QA reivew.  Thanks in advance for any help.   

[HenryLindemann]

Hi Jay,

You can first try to just publish a blank feature class E.G create a new FC and just place a point in it if that publishes then you probably have an error in your data.

Where is your data hosted? If it is not hosted on the server then that can also cause a problem.

Are you using a SQL database of a FGDB ?

Regards

Henry

[JayHodny]

Hello Henry,

Thank you for your reply. Our data are hosted on an SQL server in our ArcGIS Server site having our SQL sde enterprise geodatabase.  I am joining the City of Newark, Delaware parcel feature polygons (8,135) to zoning polygons (324).  Through some join steps I have created a feature class that shows zoning by parcel polygon. The idea is to create an editable feature service in an app where zoning on individual parcels can be updated as zoning changes are approved by our City Council and our Planning Department.  The app approach would allow our Planning department, who have some GIS skills, to make zoning changes.  I would then reconcile and post the edits to our sde. 

Yesterday when troubleshooting, I did publish a different feature class, the City of Newark boundary, one polygon, and it published fine.  As you suggest, I will create a blank feature class with one point and see if that publishes, and reply.  I hope a resolution can be found.

Kind regards,

Jay

[HenryLindemann]

Hi Jay,

You mentioned that you are using a join and that the database is a SQL server.

  Q: is the join coming form the same database?

      I am thinking that the layers or the users have a rights problem on the data.

      what some times happen is that a person connects to the data-source in database_1 and the other using database_2 but not both are registered or the ArcGIS server.

      Also make sure that the instance and user specified in the Database connection is the one registered with the server some time the database is registered but with the wrong       user or only using the server name and not the full name "FQDN"

     

Right click your server connection in ArcMap go to server properties, select Data Store then the MSSQL server that is used then click properties -the finger under the x- then click edit the details must be the same as the Database connection 

   is ODBC 13 for SQLServer installed on both the server and the station that publishes?

      I don't think this is your problem but a common problem.

   Deleting the connection Strings and recreating them might also solve the problem as they corrupt every now and then

I hope something helps

Regards

Henry

[JayHodny]

Hello Henry,

Thank you for continuing to provide ideas to help resolve my issue.  I created a simple point feature class, two point features, and attempted publishing.  I received the same error as before from the data store registered version/connection.  If I switched to another database version, I was able to publish the feature class.  I did this step a few times with other versions and all published as expected.  I deleted the database version, recreated, in Catalog.  I also deleted the data store database connection registration.  I recreated all of these items and tried again, same unfavorable result.

The joins are coming from the same database.  I think the other points you raised are set up appropriately.  Thanks, Jay

[HenryLindemann]

Hi Jay,

Ok are you using the same version of ArcMap as your Server or are you using ArcGIS Pro.

If ArcMap

Geodatabase version

when you go to the properties of your Database Connection what version is the Geodatabase

if the version is below 10.4.1 i would recommend upgrading it 

Data Store

Are you publishing to a ArcGis Data Store E.G managed database ?

   If yes you can check if the Data Store is up and working correctly.

   Navigate to the server where data store is installed

   C:\Program Files\ArcGIS\DataStore\tools

   open a administrative command prompt and run describedatastore.bat

   It should look like this 

   make sure Data store mode is ReadWrite if not you either ran our of disk space or some other error

   can can place it back in read write by running changedatastoremode.bat

Kind Regards

[AhjungKim4]

I had the same problem yesterday.  Map service published fine the day before, but the next day I started getting the  errors when all I did was changing symbols & layer name and re-publish.  I tried everything that was posted on GeoNet from removing the server account and re-adding to the database and re-giving privileges, reconnecting to server and db, authoring new MXD .  The database was registered and validated.  At the end, what worked was publishing from Pro.  When I tried to share web layer, Pro warned that the database is not registered (yes, it was using ArcMap 10.6.1. and was validated).  So I clicked the button to register it and it did the trick and published the map service. 

[JayHodny]

Ahjung,

Are you publishing directly from Pro to Server?  Are you using ArcGIS for Enterprise for this process?  We are not set up to publish from Pro to Server without Enterprise.  We do not have ArcGIS for Enterprise installed yet.  Thank you for your input and help.

Regards,

Jay

[JayHodny]

Hello Henry,

Our sde version is 10.4.0 and our ArcMap version is 10.7.1.  I see the same message in the properties (except I see 10.4.0).  We have had no other publishing issues of this kind with this setup.  We are publishing to Server from ArcMap.  We are not able to publish to Server from Pro.  We have an upgrade to ArcGIS for Enterprise in the works, but that is many months out.  In the meantime, I know we are on "thin ice" having a Server version that is several versions behind ArcMap and the ArcGIS platform in general.

We are publishing to the data store, but not a managed database.  I am fairly certain all of our database connection registrations are the non-managed type.

We cannot locate the describedatastore.bat file on our Server.  I wonder if the utility did not exist for version 10.4?  We do not have any other publishing problems, so this leads me to believe the data store mode is set to readwrite.

I suppose it is time to reach out to Esri support.  Thanks, Jay

[JayHodny]

Henry,

I have Esri support involved, but so far we have not been able to fix the issue.  There was a Server 10.4 publishing patch we installed (https://support.esri.com/en/download/7397).  The publishing error persisted despite starting the process from scratch (new MXD, database connection, new child version for editing, data store registering, etc.).

My colleagues and I are wondering if there is an issue with publishing when new child versions are created.  If we publish from a child version set up several months ago, we can publish the feature class as expected.  If I try publishing using a newly created version I was hoping our Planning department would use, so that edits can be made before rec and post, the error occurs.  We periodically perform a full database compression, where we delete the versions, compress, and re-create the same exact versions as before.  Our concern (fear) is if we compress and then rebuild, we are left with new versions that now don't allow us to publish.

Thoughts?

Jay