Model Builder arcgis 10.4 add field, calculate geometry

[paulbolstad]

In Model Builder in 10.4, I'm trying to apply a dissolve, then multipart to single part, then projection, then finally calculate areas in acres.

All the steps work until the last one, whence it says it can't open the table.

The step before (projection) works, and terminates successfully, and I've verified the new layer outdata is present. It will also work manually (applying add field from arc map)

I've attached the processing message, the block in blue is the project step, it shows it starting and ending correctly, and the red is the error message below.  I've also included the model flowchart.

I originally did this into a default data base, but the intermediate results weren't showing up, although it was running to the same step, and hanging up at the add field.  So I tried writing to files, to aid in debugging, but still no joy.

Any ideas?  Probably something simple, but I haven't been able to puzzle it out.

Thanks 

Paul B

[DanPatterson_Retired]

where are the parameters for add field? I don't see anything, are they hardcoded?

Why don't you use Add Geometry Attributes which will handle adding the appropriate fields and doing the calculation for you

[ChrisDonohue__GISP]

It is possible there is a lock on the geodatabase from previous viewing/ Modelbuilder runs.  As one example, if there is a instance of ArcCatalog pointing at data, that can lock it.

One workaround to clear any locks is to run the Compact geoprocessing tool.  This tool explicitly clears locks as part of its processing.  (Note that we are not choosing to run this tool because there are specific concerns about fragmented data related to the reported issue; instead, because we want the beneficial side effect)

Compact—Data Management toolbox | ArcGIS Desktop 

Chris Donohue, GISP

[paulbolstad]

Dan,

Thanks for the suggestion, but I tried that first before the original post, and ran into the same problem. When I saw it again with the Add Field, and after some other checking and debugging, I decided to post to the forum.

I think Chris may be correct in that it might be a lock, I found if I run the process twice, it works the second time...so I'll try with the compact geoprocessing tool, and see if that works, and get back to you when I'm back at my desk.

Thanks,

Paul B

[curtvprice]

I originally did this into a default data base, but the intermediate results weren't showing up, although it was running to the same step, and hanging up at the add field.

You may be able to avoid some of your troubles by putting your temporary datasets in a better scratch location: %scratchGDB%, or in_memory - and marking those variables as intermediate. You can delete any existing intermediate datasets in the File menu. When the model is run as a tool, the intermediate datasets will be deleted for you.

Note to add intermediate sets to the map when running your model in edit mode (ie not as a tool) you need to right click them and select Add To Display.

I doubt this is the cause of your problem, but I highly recommend you avoid using folder (or any) names that start with anything but a letter. It may work, but in my experience it's just asking for trouble along the line somewhere else.

[DanPatterson_Retired]

could also be the \t in ...\test ... depending how the folder is being treated (ie raw format, \\ or / path styles)

[paulbolstad]

Dan & Curtis, Thanks.

The Compact command worked, as I suspected it might, because the process also worked originally the second time through, or when I substituted an existing file that wasn't calculated during the run.  I didn't know about the Compact command, so good to learn.

I am a bit curious about the suggestion to not use numbers when beginning a folder name, and not using the default scratch work space.  Although for more involved models I usually define a local scratch space, I've written hundreds of small models using the default gdb, and not had a problem.  Any insights on why it should be avoided.  Same for the folder beginning with a number....what kind of problems does it cause?

Thanks,

Paul B

[DanPatterson_Retired]

esri grids are particularly sensitive to folder constructs.  I my teaching, I have had major issues... sometimes... note the last word, when the last folder in a path begins with a number.  Having said that, if the folder beginning with a number is somewhere in the middle of a path, no problem.  Go figure, it is just one of those 'rules'.  Paths on the other hand, are extremely sensitive to 'escape' sequences

path = 'c:\temp\newfolder\all_stuff'

print(path)

c:      emp
ewfolderll_stuff

# ---- raw encoding ----

path = r'c:\temp\newfolder\all_stuff'

print(path)

c:\temp\newfolder\all_stuff‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[curtvprice]

Re default workspace. The problem with using C:\users\jwpowell\Documents\ArcGIS\Default.gdb is that the default workspace is your personal workspace. If you hand the model off to someone else, they do not have access to your default scratch area. %scratchGDB% and %scratchFolder% are guaranteed writeable paths for temporary data.

Also, it's a bad idea to load up your C:\Users area with scratch data. Another strategy: I urge my students when they set up a lab to save the map document in an empty folder, create a local file geodatabase, and tag it as default. This sets the scratch and current workspace to that folder. If they set up their map document with relative paths, the whole folder can be transported somewhere else and models etc will work.