I also run into the problem with the fme_schema_handling=schema_only using multiple features (with an error that tell you nothing), so I now do that differently in my processes. Yes, irritating but not enough for me to raise it as a case.

As for the other things: Your coded_domain syntax appears incorrect. You show as coded_domain(CodeLightingCategory:text

but it should be:

coded_domain(CodeLightingCategory:char

And also your alias syntax should be (unless they have included it like that in 2022). It is not included in the attribute{} list, so appears as a normal attribute.

<fieldname>_alias

e.g lightingCategory_alias = Lighting Category

Cheers,

Todd

N.B. If you need an example, send me an email and I can send you an example.

Also, personally I don't use the domain creation in FME because I seem to have domains that are constantly being added to, description changed etc which I do not believe FME can alter. If that is likely to be something you face, I would say you are better to build a workspace that incorporates ArcPy into it and can handle any domain situation. We have, and it is great.

@Todd Davis​ -- Yes, the fme_schema_handling attribute does seems to be a problem. Did you ever find a workaround in FME for the error you were getting?

@Todd Davis​ -- Understood about data type and alias attribute name errors I am making. Thank you. The data type issue brings up a question, though: Is there any specific Safe documentation of the Esri "native data types" that FME is expecting? Everywhere I look in Esri documentation has the data type for characters/strings as "text."

Re: Workaround for schema handling. In our main process we pull in arcpy to do a couple of Esri things, so I just use a deletefeatures at that point, but if I was not doing that I would do this...Insert feature and create the schema, and then run a delete operation of the layer by:

1) before writing schema layer add an attributecreator and create fme_db_operation = INSERT

2) then create another branch with another attributecreator and create fme_db_operation = DELETE (if you do that in that order the runtime order will be correct otherwise you need to correct in "Set Runtime Connection Order" to make sure the insert works before the delete)

3) Set up feature Operation in the writer to consume fme_db_operation and where clause to be 1=1

4) Maintain the rest of your schema writing setup

Below is 1-3 (excluding schema writing setup)

As for what FME data types it is expecting, I just have found the domain values from Safe's writeup(s) but I have not found a defined values in the documentation. For standard native_data_type schema stuff, I have just learnt by reading in a layers that already has it using a featurereader and then looking at the schema outputs. But again, like lots of things, the more you do it, the more your own knowledge grows.

@Todd Davis​ -- Thanks for this. You are, of course, correct about gleaning info from a FeatureReader and about learning in general just by doing. I did inspect the schema from a FeatureReader, and I implemented your FME-based workaround above, using the fme_db_operation attribute. Makes perfect sense and should work, but, alas, my workspace is still choking. I will pound on this for a bit more, but I think the continued problems are just screaming for a straightforward arcpy/fmeobjects solution, which I always think of first anyway and am far more experienced with and better at than the minimal-Esri or pure FME solutions my organization normally seeks. I will likely be arguing for some flexibility in this case. Thanks again for all your patience and help.

If you want, you could send me the FFS of the feature that sets the schema of a table you are trying to create. I can then have a look and see if I can spot anything that may be causing an issue. You should be able to find my contact details quickly via the internet.