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