An expected Field was not found or could not be retrieved properly [created_user]

[MaryDuBose]

I have two ArcSDE feature classes that I am trying to set up for versioned editing with ArcPro. I have set the appropriate privileges, added Global IDs, enabled versioning, and enabled editor tracking. However, when I pull the layers into ArcPro and test creating a new feature, I get the error "Failed to create new feature(s). An expected Field was not found or could not be retrieved properly. [created_user]"

All 4 editor tracking fields exist, and when I open the attribute table, I can see them just fine. They are set to read-only, but I have other feature classes that do not have this error, and their editor tracking fields are also set to read-only. Also, I tried switching them to not be read-only, and that did not resolve the issue.

Any ideas on how to go about troubleshooting this? I already tried disabling and re-enabling editor tracking on the dataset.

The feature classes are already populated with data that I imported into the ArcSDE geodatabase from a file geodatabase. I need for editors to be able to create new features as well as edit existing features. Oddly enough, when I try editing an existing feature, the error that pops up says "Edit operation failed. An expected Field was not found or could not be retrieved properly. [created_user]". Even though the created_user field shouldn't be changed with this operation - only last_edited_user.

[Robert_LeClair]

Try this - copy/paste the 2 SDE FC's a file geodatabase.  Delete the 2 SDE FC's from your eGDB.  Run the Check Geometry and Repair Geometry GP tools on the 2 fGDB FC's.  Copy/paste the 2 FC's from the fGdB to the eGDB and retry the workflow.  What is the result?  Please advise.

[MaryDuBose]

Hi Robert, I tried this and after copying the FCs back into the eGDB, I am able to set the correct privileges and enable editor tracking, but when I try to register them as versioned, I get Error 002941: "An expected Field was not found or could not be retrieved properly". So basically the same as the original error, but happening at an earlier stage of the process, since before, I did not have any issues registering as versioned.

[Robert_LeClair]

Hi Mary - are you using traditional versioning or branch versioning?  One thing I would try is delete the FC from the eGDB again, copy/paste back into your eGDB, set privileges, register as versioned, and add GlobalID's.  If that's successful, then enable editor tracking.  What is the result?

[MaryDuBose]

Using traditional versioning, and the FCs are in a feature dataset, if that's relevant. I tried deleting and re-adding the FCs, and when I try to register as versioned this time (before enabling editor tracking), I get the same error (Error 002941).

[Robert_LeClair]

Hmmm...I wonder if something is up with the FDS itself.  Another test, create a new FDS in a new eGDB, copy/paste the eGDB FC's from the old eGDB to the new eGDB using an owner connection.  Retry the workflow. 

Or if you don't want to create a new eGDB, just create a new FDS in your original eGDB and copy/paste the FC's across.  They'll get an _1 appended to their names.  Retry the workflow.   What is the result?

[MaryDuBose]

I created the new FDS in the original eGDB, copied and pasted the FCs, followed the workflow from your previous reply and that all worked correctly -- I was able to register as versioned and enable editor tracking without any errors. But when I tried adding the new FCs to a map to Pro and creating a new feature, I again get the same error as in the original post. 

[Robert_LeClair]

Well at least we're getting some progress.  Okay next idea.  Create a new eGDB and create an owner database connection.  Create a new FDS in the new eGDB and copy/paste the FC's from one eGDB to the new eGDB and retry the workflow.  What RDBMS are you using?

[louielou1234]

I was getting the same error and it turned out that it was because the dataset had a lock on it.  As soon as I released that lock, the error went away.

[JoeBorgione]

Just my two cents when it comes to feature datasets in the enterprise (sde) environment:

In the past I have always avoided using FDS in that environment.  They have a tendency to misbehave with the multi editor functionality having schema locks at the worst time.

The EGDB (sde) is great when it comes to editing and data storage, and I've used it as such for many years.  However, if you have special needs like a streets network that requires a fds, I recommend storing and editing the data in your EGDB as feature classes, and then create a workflow to push them to a FDS within a file geodatabase.

One  such workflow that I've used is to truncate the FGDB/FDS feature classes and then append the EGDB-feature classes accordingly.