The solution for the error of This geodatabase does not support this client or operation. seems to be the database version I was trying to write to.
Since 10.9 versions does not know about datatypes like date_only, and I added an attribute of date_only to the schema the writing part failed.
The suffix of _[geometry type] to the feature class name in the database seems to be a bug.
I am reading the input data from a zipped geopackage, and FME shows the geopackage_type as geopackage_polygon. In my case, the fme_feature_type would be lakes, and the resulting name of the feature class is lakes_polygon.
I tried to circumvent the suffix, fishing with a regular expression for possible parts, separated by an underscore - to no avail.
Since the feature information in the Workbench do show fme_feature_type with a value of lakes, right until the Geodatabase_SDE writer, and even setting the regex in the settings of the writer shows no effect, I assume it is a bug within the writer.
The suffix is also shown when using the Geodatabase_File writer...
After the attempt to write the data into a file geodatabase, and getting the same result as with the enterprise database, I renamed the feature class in the file geodatabase by deleting the suffix.
Then I read the file geodatabase in the same workspace, and used the same dynamic writer to the enterprise database as I used before... this time the name of the resulting feature class in the enterprise database did not receive any suffix and is simply called lakes, as expected.
In the end I used the SchemaScanner, and for good measure I left the regex in the writer settings for the feature class name.
I am using the Data Interoperability Workbench in version 2023.1.1.1, build 23636
- We are living in the 21st century.
GIS moved on and nobody needs a format consisting out of at least three files! No, nobody needs shapefiles, not even for the sake of an exchange format. Folks, use GeoPackage to exchange data with other GIS!