Esri Workspace XML to FME dropping first record

Question

I am working with some Esri Workspace XML documents supplied by a third party. These have (for years) successfully loaded via python into Personal GDB for minor attribution before being imported into the enterprise GDB.

Now our database structure is changing and I have been tasked with creating an FME translation to read these XML files and write them into the new structure.

I have discovered, however, that FME drops or ignores the first record for every feature class in the XML. It appears that the Workspace XML files have an ObjectID 0 for the first feature in a feature class (much the same as in a Personal), but FME seems to want them to start at ObjectID 1 (like a File GDB or Enterprise GDB).

How can I get FME to accept the ObjectID 0 features? There is nothing wrong with these features - they will import into Personal GDB no problem, and if I change the 0 to another number like 999 in the XML they are read by FME no problem, but since they are value Esri XML files I would expect FME to be able to see them as is.

Currently I have a workaround that re-numbers the 0 to 999 before we run the FME translation, however this isn't a great long-term solution.

Answer 1

Hmmm. Yes, FME might be ignoring that feature with ObjectID = 0. However, the Esri documentation that was shown to me says:

ObjectID fields are sequential and start with the number 1 for geodatabase data. For shapefiles and dBASE tables, the OID or FID column begins at 0.

So we might be deliberately ignoring that because technically, 0 is not a valid value for an ObjectID. At least, that's how I read it.

The other possibility is that the first feature might get treated as a schema feature by FME, if the workspace is "dynamic". I'm less inclined to think it's that, but one way to tell is to read the data directly using the FME Data Inspector. Also, check for an attribute fme_schema_handling with the value 'schema_only'. That would indicate it's schema only.

But I'm more inclined to think it's because of the ObjectID. I can raise that as an issue with our developers, but I can't guarantee that they'd change anything if they also believed that 0 is not valid.