Issue Copying from Editor Tracking Fields

[JohnStreeb]

I upgraded from ArcGIS Pro 2.9 to 3.1.1 and at the same time updated dltsolutions to the 3.1.1 version in Package Manager.  After the update however, some fields are not copying data over.

In a Data Loading Workspace, where there are fields in the source dataset that have Editor Tracking enabled on them, and they are added in the data loading workspace for a particular target dataset as an expression (ex: TargetField: CreationUser  |  Expression: !CreationUser!) it fails to copy any data over into those fields in the target dataset now after the update.

To clarify some details:

• It was copying over all data correctly until the version updates.
• All other fields are copying over correctly, it's only where the source field is used for editor tracking that it's not copying the field value
• The corresponding field in the target dataset is NOT configured for editor tracking (Editor Tracking is only enabled in the Source Dataset)
• From limited testing, this same error behavior does NOT occur via the Append with Transformation tool, only via a Data Loading Workspace.

Am I missing something or has anyone else encountered this and found a work-around?

[MikeMillerGIS]

I created a simple test and I could not repo with 3.1.1.  Can you share a zip with your data loading workspace so we can review?

[JohnStreeb]

I sent a direct message with Data Loading Workspace for testing.

As an update, for now, as a work-around, the current project is pretty simple field mappings, so I've migrated them to use the AppendWithTransformation with the same mappings copied over.

[JohnStreeb]

So, after playing around with it a bit more, it appears it is in fact still having the same issue, even with the AppendWithTransformation tool.  However, I've narrowed it down a little.  When I do a very simple run, where every target field has a source expression of !SourceFieldName! there's no issues.  However, if there's a more complex expression in one of the fields ex: 

!SourceFieldName!.split('-')[0].strip() if !SourceFieldName! else None

then the other field map for fields in source dataset that are editor tracking fields ex:

TargetField: CreationUser  |  Expression: !CreationUser!

don't copy values into those fields (in above example: CreationUser field in target dataset is empty, even though source dataset has values.

Not sure if this helps, but hopefully.  Please let me know if there's anything else I can provide to help get this fixed!

[MikeMillerGIS]

We were able to repo the issue and narrowed it down to a change in how the FieldMapping object auto matched rows.  In 3.1, the ET fields do not auto load.  You can see this by just using append(screen shot below, notice how the ET fields have a (0) next to them, showing they did not match the source to target fields).

We have fixed this the DLT loading tools and finalizing some testing.  I hope we can get an update on conda next week to resolve it.

[JohnStreeb]

Thank you, I appreciate the information and look forward to the update!

[TedHoward2 · Accepted solution]

3.1.2 is available and will fix this issue

[JohnStreeb]

Thank you very much for getting this fixed!  I updated and it appears to be working!

Also, as an FYI, I did happen across another slight difference that has an easy work-around, so it's not a problem, but I figured I'd pass along anyway in case it's helpful.  In 2.9.5, I had a DataLoadingWorkspace with some target dataset mappings having text fields configured with an expression like:

!SourceTextField![:50]

in order to trim a longer source field down to the target field's field length.  For those fields, when the source dataset's value was Null, it would simply set those fields for those features to Null as well.  However, when moving to 3.1.2 (I didn't check specifically at 3.1.1) it ended up erroring out.  I was able to isolate it to this particular issue since only changing all occurrences of those expressions instead to:

!SourceTextField![:50] if !SourceTextField! else None

appears to have fixed the problem and it's running without errors again.  Like I said, this isn't really a problem as it has an easy fix that makes it a better Python expression anyway, but, I found it an interesting difference in how 2.9.5 vs 3.1.2 DLT appears to be handling Null values or Python Expression type errors or whatever specifically is going on behind the scenes in DLT, so I'm just passing it along.

Anyway, thank you again very much for the expedient help getting this issue resolved!  I have made a lot of use of the DLT solution throughout a number of my workflows, so, having this operating correctly again in the updated version is great!  Thanks!