Python Script Dissolve (in_)memory Error

[TylerT]

Hello,

The following code produces an the following error:

fc_mem_1 = r"memory\temp_1"
...
fc_mem_2 = r"memory\temp_2" # memory fails, use in_memory
arcpy.analysis.PairwiseDissolve(fc_mem_1, fc_mem_2, 'cl_id', statistics_fields=stat_fields, multi_part='MULTI_PART')

While the following code does not produce an error:

fc_mem_1 = r"memory\temp_1"
...
fc_mem_2 = r"in_memory\temp_2"
arcpy.analysis.PairwiseDissolve(fc_mem_1, fc_mem_2, 'cl_id', statistics_fields=stat_fields, multi_part='MULTI_PART')

I understand in_memory to be a legacy workspace.  Is this expected behavior with PairwiseDissolve and Dissolve?

Thank you,

Tyler

ArcGIS Pro 3.1.0

[MErikReedAugusta]

Somehow I missed the boat on "IN_MEMORY" becoming "MEMORY".  Do you have sources on that?  Because I clearly need to catch up on some reading.

[BlakeTerhune]

Write geoprocessing output to memory—ArcGIS Pro | Documentation

[KimOllivier]

Yes, well the Pro developers forgot to read the ArcMap manuals.... there is now a synonym to patch up the syntax. I presume that it is a different mechanism under the hood. It never worked reliably for me anyway, so I just use an SSD drive as my scratch.gdb. You can easily run out of memory if you do not release the features, and who does that? Also projections did not work etc.

[KimOllivier]

Save (in_)memory for simple tasks. It is a lot of people's experience that it does not always work for complex tasks like Dissolve. It did not work for me with geometry objects or reprojections.  If you have an SSD then define a partition or just a disk letter and use that for the scratch.gdb and other temporary featureclasses. Since it is effectively equivalent hardware you will get all the benefits of cached read/writes and more reliable operation with the same speed and not run out of memory.