Select to view content in your preferred language

ERROR 001270: Consolidating the data failed.

49127
61
07-30-2012 07:43 AM
YimanSong
New Contributor III
I got this error when I try to publish a tiled map service to ArcGIS Online through ArcMap. Does anyone know why?
Tags (2)
61 Replies
roemhildtg
Occasional Contributor III

I ran into this issue because I had a table that was stored in a personal database (mdb). This table was joined with a feature class. ArcMap gave me the warning (data will be copied to the server) which I was fine with but the error occurred. 

Removing the table and the join got rid of the error for me, so I'm guessing ArcMap doesn't fully support publishing data stored in an mdb. 

Running ArcMap 10.4.1 (64 bit) and Server 10.4.1. 

0 Kudos
NathanHeick
Occasional Contributor II

I had similar issues while publishing a feature service from ArcGIS Desktop 10.1 from file geodatabase data to ArcGIS Online.  I was able to fix the problem by making two changes.  First of all, the data is on a mapped network drive.  I had no problem publishing this feature service to AGOL from ArcGIS Desktop using Share as Service.  However, when automating the process, the StageService tool wouldn't consolidate the data.  I fixed that partially by using UNC paths instead of mapped drives in the .mxd.  We have had to do that on other feature services to publish to AGOL.  Second, the StageService tool seems to prefer absolute paths.  I got it to work with both mapped drives and full UNC paths, however, the .mxd still needed to use UNC paths.  Therefore, I settled on UNC paths for both for simplicity.  Many of the arcpy.mapping tools gave me no issues with using relative paths and writing to the current directory using just the filename.  I suspect that the StageService tool does a lot of data path validation and, under certain circumstances, ends up comparing a UNC path to a mapped network drive path, and rejects them even though they represent the same resource.

0 Kudos
NathanielEskridge
New Contributor

Received ERROR 001270: Consolidating the data failed after re-organizing some features from a temp GDB and .mxd to a Final version GDB and .mxd. Issue appears to have stemmed from dragging the feature from one .mxd to my new, to be published, .mxd version. Or was from moving features within the Final GDB. Tried changing Staging and did not help. Noticed Gary Sheppard Employee Oct 16, 2015 6:09 AM and thought that would help. It did. I simply opened layer properties for each in ArcGIS .mxd TOC and made sure paths went to correct feature location. I have noticed that Arc "Sees" the same name of a Feature regardless of being in a Feature Dataset or directly under the root GDB.

SheaO_Neill2
New Contributor

Hello All,

I struggled with this as well. I tried reducing path names -- but to no avail. Ultimately what worked for me was removing several CSVs and DBF tables that were hiding in my MXD. I am not sure if this is a universal problem solver -- but may work for some?

0 Kudos
DavidWeisgerber
New Contributor

Hey gang... same problem. I finally exported the versioned SDE into a shapefile then uploaded from that and it worked. Pain in the butt to be sure

0 Kudos
YuandaZhu
New Contributor II

Currently I am using 10.3.1.4959. When I created a new MXD and trying to publish as a map service, the same error popped up. Tried everything mentioned in this thread but nothing really worked. What I did in the end is to find an old MXD file which have published successfully service previously, renamed it and copied the layers over, and then published the service with the old MXD file. No problem anymore. I did noticed that the old MXD file is much smaller in size.

Don't know why this happen.

0 Kudos
JeffersonValencia_Gómez
New Contributor

I'm using ArcGIS 10.5, specifically ArcMap, and I had to apply a combination of many solutions provided here in order to be able to replace an existing service. The steps are the following:

- The layers to be published as service were stored on a GDB so I created a new GDB and exported all my layers into this one.

- I saved the MXD file (Save As) with a different name and loaded the exported layers through right click each layer, select properties, select the source tab, and selecting the corresponding layer exported into the new GDB.

Those steps were enough to finally publish the service succesfully.

Good luck and I hope my solution helps you.

Best,

0 Kudos
jeenolazarau
New Contributor

Tried everything from this thread. For 2 days... Nothing worked. Surly, client wasn't getting impressed with nothing being updated on the webmap.  

This morning one of our guys that copy and paste to database came up saying he can't add data to one of the layers.... and that one layer was was corrupted. Used fix geometry and all went well from there on. 

If that's your case I think you can batch check geometry on multiple layers. Hope this helps.  

0 Kudos
JohnFarrell3
New Contributor II

I received this error when attempting to publish to ArcGIS Online from an ArcSDE feature dataset.  Esri suggested I create a brand new feature dataset and copy the feature classes into it, then try publishing again. It worked.  The old feature dataset was branded the culprit and was then retired as "corrupted".

Katie_Clark
MVP Regular Contributor

Had this issue today - tried a bunch of different things to troubleshoot, but finally found out that the issue was that the data was PolylineZM instead of just Polyline. I thought I had taken care of that because I disabled M and Z values in my environment settings, but I ended up using the Feature Class to Feature Class tool on all of my layers to turn them into simple Polylines and then I was able to publish. 

Found that suggestion from this blog: Anna's Hydrology Blog: Get rid of Polyline ZM 

Hopefully this can help someone, it's interesting to see so many different solutions in this thread! I agree that a more specific error message would be more helpful 

Best,
Katie


“The goal is not simply to ‘work hard, play hard.’ The goal is to make our work and our play indistinguishable.”
- Simon Sinek
0 Kudos