Populate File Geodatabase Attribute with default value

It seems pretty clear, that FileGeoDB writer doesn't handle default values properly.

It seems for a NOT NULL field always default 0 is used instead of the predefined default value.

Now I tried a workaround by using a Schema Reader, but I was not able to get as deep in the schema info as to read the predefined default values.

Any ideas how to get a more complete schema definition, which also provides predefined default values for a field ?

Thanks

Michael

For the moment, only solution which I see as achievable is that we introduce a PythonCaller which will through ArcPy pick up all attributes with default value and initialize them. Of course, possibility to define default value on the FCL value as well as on the subtype level is making things a bit complex, but I assume this is possible.

Nevertheless, I do not understand why would FGDB Writer ignore attribute’s default value.

Does it make any difference if you use a template file? (I don't have access to ArcGIS to check)

I tried to use a XML Template File, but FME complained that target schema is already existing and stopped the migration.

I didnt tried to use FGDB as a template because in that case, if I do not make a mistake, I would have to owerwrite the target database.

My thoughts were the same as @ebygomm : Use a blank FDGB as a Template with the Field Default Values set using ArcCatalog.

Tested with the FileGeoDB Open API Writer. It works: Any new Features added are assigned the Default Field Value if no value otherwise set by the Writer.

To use:

• In the Writer, set the path to the FGDB you wish to create. Make this a new FGDB that doesn't exist
• In the Writer Parameters, turn On "Overwrite Existing Geodatabase"
• In Template File Geodatabase, select the path of the Template FGDB

This does not overwrite the Template FGDB. It takes a copy of it and uses it to create and write to a new FGDB.

Since it appears you already have the Schema in a Geodatabase, then a Template FGDB can be created easily enough by using the "Copy" ArcTool in ArcGIS. This copies everything from a source GDB to a new template FGDB: Domains, SubTypes, Default Field Values, Indices etc. (although I would probably drop the indices in a template FGDB)

To "blank" the tables back to zero records in the Template FGDB, use the "Truncate" ArcTool.

Thanks for your test @bwn

I tried your workflow with the Open API Writer and indeed the features went inside, but there is no data validation option on the Open API Writer so I cannot be 100% sure if the data written are correct.

Nevertheless, I wanted to check data written in the target FGDB, but as soon as I open FGDB in Catalog panel of ArcGIS Pro, software takes in some half minute complete available memory of the PC (it reaches ca. 26GB) and crashes before the table content is opened. I have no idea what is actualy written inside the FCL.

Can you please tell me are you using ArcGIS Pro or ArcMap to check the written data? It can happen that FGDB created by FME from the template file cannot be red by the Pro. @markatsafe mentioned me in one of my posts that upgrade to Arcobjects 11 will not be full implemented before FME 2020. Maybe ArcGIS Pro crash which I experienced is a consequence of this ArcObjects vs ArcPro SDK mismatch...

I also tested the template file option with the Geodatabase Writer, but there I receive the same error as without template file.

For testing, limit the number of features written to start with to say 100 using the Sampler Transformer. This is to test that default values are being created in FGDB fields with a Default value set.

If Pro is having problems, the written FGDB can be read back into FME to check that default values got created and viewed in an FME Inspector. On the FGDB Reader used to check a sample of Features, a limit can be set as to the maximum number of Features to read. Again this is just for testing that default values did get created by the Writer.

An alternative viewer to FME is QGIS.

Can't say why Pro would have problems. It should be able to deal with regular FGDBs fine, but can depend on the data within it.