Skip to main content
  • EN

I need to write a couple of 100 tables from postgis into several geopackage files.

This should be a pretty simple job? But the workbench fail

OGCGEOPACKAGE writer: OGCGEOPACKAGE writer: For feature type 'd_y_n', primary key attribute 'id' has unsupported type 'mediumint'. Primary key must have type 'int'

 

This is related to https://community.safe.com/s/question/0D54Q00009SAyLQSA1/geopackage-dynamic-writer-error-unsupported-type-mediumint?t=1669103461721 and a follow up https://community.safe.com/s/question/0D54Q00009w0K1ZSAU/ogcgeopackage-writer-primary-key-attribute-id-has-unsupported-type-mediumint?t=1694607976804

 

"It seems like FME is trying to write a 32b integer when its expecting a 64b integer"

 

Is there a solution to this problem?

 

I need something stable to run in a production environment, this job will run nightly.

 

I can easily script what I want to achieve using ogr2ogr (append several postgis tables into one or several gpkg)

Simple example to append a table to an existing gpkg database.

ogr2ogr -f "GPKG" "c:\\temp\\export.gpkg" PG:"host=pgprod port=5432 dbname=DB user=USRpassword=PWD" "SCHEMA.TABLE" -append

 

But i wish to use FME instead of having several different scripts and routines.

Any ideas?

 

 

I understand that it is a workaround, but does the search for "fme_int32,PrimaryKey" and replace with "fme_int64,PrimaryKey" in the schemafeatures list not work for you?

I understand that it is a workaround, but does the search for "fme_int32,PrimaryKey" and replace with "fme_int64,PrimaryKey" in the schemafeatures list not work for you?

I never actually tried the workaround because I am not so used to using dynamic writers so I did not figure out what meny/tool to use to do the replace operation.

I am also always cautious for workarounds. Suddenly the workaround does not work or it adds complexity that cascade into other issues to the point it become unmanageable and you need to start from the beginning.

But I am not oppsed to try the work around if it will be stable enough for potentially several years ahead of time. Just need to find how to do it

@so_much_more​ , my experience with the mysterious "d_y_n" error is a bit different, but it may be helpful.

 

I ran into the error when dynamically creating FGDB from an enterprise geodatabase yesterday. In my case, the issue was not at the schema level but was at the feature level. I could track down the individual features that had resulted in the fatal message: they all had "null" geometry! When I filtered out those features, my form worked as designed.

 

BTW, I was using FME Form 2022.2

 

Reply


Community Stats

30,108
Posts
114,295
Replies
37,745
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.