Map 3D 2020 Edit GDB, Error when trying to Check in feature

[anthony_ostermiller-ecord]

I'm trying to edit the tables of a GDB.  I connect by using the FGDB and bring in the feature class I'm working on.  I find the objects that I need to edit, change the field in the Feature properties and then try to Check-In Features.  That's when I get the following errors:

Feature was not saved in the target feature source.          

Failed to update feature.

1=Failed to execute Fdo command.

2=ESRI: The field is not nullable. [sdsId]

PW_Electrical:ElectricalUtilitySegment_L (505), Rev# <-1>

Feature was not saved in the target feature source.

Failed to update feature.

1=Failed to execute Fdo command.

2=ESRI: The field is not nullable. [sdsId]

PW_Electrical:ElectricalUtilitySegment_L (328), Rev# <-1>

Failed to save edit set.

Failed to update feature.

Failed to execute Fdo command.

ESRI: The field is not nullable. [sdsId]

Failed to save edit set.

The sdsId is not null, it has an object id that was assigned in ArcGIS.

There are other fields that are <Null>, but it came that way from ArcGIS.

Is there a step I'm missing?

[ChicagoLooper]

First, Checkout.

Perform edits.

When done, Check in. 

[anthony_ostermiller-ecord]

I have automatic checkout selected.

[ChicagoLooper]

On a side note, are you able to get the Table View of your data? Does the pencil icon appear in the far left column of the Table when you Check Out? Then when you Check In, the pencil icon goes away.   

[anthony_ostermiller-ecord]

Yes, I can get to the table view and a pencil icon shows up when I edit a field.

I tried to check-in manually two ways, 1. right clicking the feature class in the Display Manager in the Task Pane, and through the Check-in button on the Vector Layer Ribbon pane.

Both show the error above.

[anthony_ostermiller-ecord]

The problem has partially been solved, I found out that the field that cannot be nullable is a GPUID data type, which AutoCAD map doesn't like.

This question now becomes how do I work with a FGDB that has a field whose data type is GPUID.

[ChicagoLooper]

Hmmmm.....I take it this to  mean the GPUID is some sort of index, where no two GPUID's are the same. May I ask why you want to make the GPUID null? What purpose does it serve when you make the value is null?

[anthony_ostermiller-ecord]

Sorry, I forgot to include a little more information about the progress.

The field (sdsid) that cannot be nullable, is not null.  There was a pre-populated id produced while the gdb was open in ArcMap that is required by the client.

The field (sdsid) is not removable when the field type is viewed in ArcMap.  A coworker had to use SQL to remove the field (not ideal).  I then connected to the gdb in AutoCAD Map, edited an entry in another field and checked the data in, there were no errors. And the database when viewed in ArcCatalog showed the edited data.

I accidentally typed GPUID instead of GUID in my previous post.

The field (sdsid) with the data type set to GUID is the only field in the table with that data type, everything else is integer, long, text, etc.  We cannot change the data type, and creating a copy of the GUID field with a different data type will produce errors when we deliver the data to the client.

Also, rejoining the field creates a different data type.

So I guess from here I have to put in a request to Autodesk to request a recognizable data type of GUID.

Unless there is known workaround/workflow besides using sql to remove a non-removable required field.

[ChicagoLooper]

---

@anthony_ostermiller-ecord wrote:

The field (sdsid) is not removable when the field type is viewed in ArcMap.  A coworker had to use SQL to remove the field (not ideal). 

---

Sorry, I don't follow you.

Can the sdsid be viewed in Map3D? Is it possible to ignore the sdsid in Map3D and make your edits anyway? Are you saying you can't make edits in Map3D without first removing the sdsid using SQL? 

If the sdsid is a field required by your client, then how do you add it back after your coworker has removed it?

[anthony_ostermiller-ecord]

First, Thank you for answering and trying to understand my problem, I really appreciate it.

Yes the sdsid can be viewed in map3D.  I've tried deleting and changing the data in the table for that row, with no success.  And I can make edits, but as soon as I do a check-in, I get the error in my first post.

In trying to narrow down the issue, we decided to remove the offending field, sdsid.  I reran a test in which I edited data in a different field and checked-in the data with no errors.  Closed the GDB in map3D, opened the GDB in ArcCatalog and noticed the edit was there.  We then tried to bring the field back in with a join in ArcMap, only to find the field type had been changed to GlobalID.

[ChicagoLooper]

OK, it's beginning to make more sense. The sdsid, that you call the offending field, sounds like a 'unique identifier.'  I know different programs use different terms.e.g. AdMapKey (Map3D), FeatId (ESRI shape), etc. Why everyone can't use the same term for the Unique Identifier is beyond me. I know each row in table view (all records), must have a unique identifier. It seems, at least to me, when trying to make edits in Map 3D, the sdsid is not recognized as a unique identifier and Map3D, for some reason, considers the row offensive.

Don't know what to say. I don't work with gdb much. It seems like you got it all figured out and that's great!!

In my little corner of the world, I'd pull the feature class out of the gdb and save as a shapefile, then edit the shapefile, but that's just me.  

[anthony_ostermiller-ecord]

Yeah, it is yet another unique identifier.  Unfortunately the data type won't allow me to post changes.

I may try the convert to shapefile path and see if it works.

[ChicagoLooper]

As I understand it, unique identifiers  are untouchable. This is b/c the program must have a way to distinguish one record from another, without ever getting confused, hence the term unique. You can try copying the field and editing the copy, but I don't think you are permitted to modify the unique identifier itself.

Typically, there are other ways, such as using another field, to identify and isolate a record (or a group of records) in order to manipulate them.