nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ErrorMessage: Failed to publish web layer

wilcow

Attempting to publish Enterprise GIS layers to AGO and after an hour or so, I receive this message:

Server Response: {"error":{"code":400,"message":"Invalid URL","details":["Invalid URL"]}}

I've seen this error when trying to publish features with Definition Queries, but none of these layers have DQs.

A couple of them do have related tables, but I removed those on the latest attempt to no avail.

There are a ton of features in the project I'm publishing - could this be a simple time-out issue?

Find more posts tagged with

Desktop

Feature Services

Accepted answers

SillPaul

I had the same problem and error message when attempting to publish to a hosted feature layer on AGO recently. I found that correcting a few coded-value domain busts in the feature class resolved this issue.

Robert LeClair

Okay something is "up" with those fields. How about creating new DATE fields, selecting all the records minus the ones with the 12/30/1899 values, field calc on the new DATE fields and keying in the correct dates for the ones that are 12/30/1899. Then delete the old DATE fields and try to publish.

All comments

SillPaul

Robert LeClair

For BUG-000111131, the workaround is to upgrade to 10.6.1 or higher. If you can't, then the proposed workaround is to populate with some type of data, yes.

For BUG-000117825/BUG-000097813, the workaround is to create a new text field and populate the date values from the data field using the Field Calculator. Enable time on the start date specifying the time zone. The data will appear in ArcGIS Online.

BrandonLee1

Thanks for the update on the updates! So my work-around would be to populate all of the null date fields then?

Robert LeClair

Hi Brandon - yes there is an update on the two bugs:

BUG-000111131 : If a time zone is set on a feature service in ArcGIS Server, if edits are not made on the date field and the date is null, the date field will auto-populate with 12/30/1899. (Fixed at 10.6.1)

BUG-000097813 : When setting a time zone on a map service in ArcGIS Server, if edits are not made in an ArcGIS Online web map to the date field and the date field is blank, the date field will auto-populate with 12/30/1899. ( Is similar to BUG-000117825 - Publishing a feature service with a date field having null values and time enabled on it shows no feature in ArcGIS Online. In the internals, both show fixed 1/16/2020 but I can't find the release number)

BrandonLee1

Any update on this @Robert_LeClair ?

I am also using Pro 3.0. Data is from a SDE using ArcGIS Server 10.6, and is part of the geometric network. There are 7 layers with Definition Queries. There are plenty <null> Date fields as well as Date Fields that have a value of 1/1/1900.

StatusMessage: Server Response: {"error":{"code":400,"message":"Invalid URL","details":["Invalid URL"]}}

StatusMessage: Server Response: ERROR: code:400, Invalid URL, Invalid URL, Bad syntax in request.

Esad

I have the same issue and I use Pro 3.0. The original data is coming from SDE and It does not let me publish to AGO but when I make a copy of it inside SDE, I can publish. As discussed in this post before, the data has date fields with NULL values.

wilcow

Thanks for your help on this!

Robert LeClair

Not sure but there are a few bug reports somewhat related to what you're seeing:

BUG-000111131 : If a time zone is set on a feature service in ArcGIS Server, if edits are not made on the date field and the date is null, the date field will auto-populate with 12/30/1899.

There were some notes internally about the issue occurring when a hosted feature layer consisting of a date field is republished and then again exported as a file geodatabase from ArcGIS Online/Portal. Also trying to view the fields to change the default value will throw the error. It was observed in ArcGIS Pro 2.4.2 and ArcGIS Pro 2.5 (Alpha 3). Those bugs are to be fixed at 2.8 it seems.

wilcow

Agreed. I saw this on several other datasets and replacing the DATE fields is what fixed it then.

Any idea whether the issue is with the data or with ArcGIS Pro?

Robert LeClair

wilcow

😖changing the values didn't work. still get an error when attempting to publish that FC.

Robert LeClair

Aha! We're on to something! Good to hear the initial test worked without the DATE fields. I'll be curious to hear the new test with the 12/30/1899 fields changed to something more current.

wilcow

Done. Out of 4 Date fields I found 2 that contained "12/30/1899".

I removed those fields and was able to publish the Feature Layer to AGO.

I'm going to test whether changing that value might have an effect on one of the other FCs

Robert LeClair

Okay - test this. Create a copy of the FC in your geodatabase. Delete the date fields, try to publish as a web layer. Success or not so much?

wilcow

as a matter of fact they do. Yes to both.

I seem to recall this being an issue when I created these features - had to add and calculate new date fields for several datasets, I think

Robert LeClair

Question - do any of your FC tables have a date field and if so, do you see a value of 12/30/1899? Weird I know but I'm researching some BUGs that talk about this.

wilcow

More on this: found several other FC's in the map and discovered I can ID which ones will work by looking at their attribute tables in ArcGIS Pro

for the FCs that fail on publishing, the attribute table appears to be blank (no rows or headers and no active tools)

I'll upload a screen shot

edit: these same FCs work as expected in ArcMap (v10.6) - I can see the attribute table, anyway

headwalls_no_atttable.png

wilcow

I tested that process (export to .SHP and reimport to GDB and then publish) and it worked for that FC.

Now I'll add it back into the project and see if it still errors out.

Robert LeClair

Depending if that one FC has any behaviors on it (i.e. subtype, domain, etc.), you could export it out as a shapefile and reimport it as a geodatabase feature class to see if that "fixes" it. Then reshare to a web layer. What is the result - error or success?

wilcow

Yessir I was publishing all at once. I tried to publish them one by one as you suggested and got the same error on the first FC I tried.

to be sure, I opened a new project and tried the same FC by itself - same result, so it seems that there's a problem with that FC.

Robert LeClair

Are you publishing all the layers out at once and receive this message? You could test each layers success (or failure) of publishing as a web layer by selecting each one individually, right-clicking on the selected layer->Sharing->Share as web layer to see which one errors out.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.