Is hard to tell but I have a suggestion. Based on your first image, I would change table handling from "use existing" to "drop and create". If the table was created without geometry it will continue to just write attributes and no geometry no matter what you change in your script.

Good luck.

It could be a number of things.

Is the output table set up correctly, has the right geometry datatype for the AREA column, and any metadata Oracle might need? As said above, setting to "drop and create" for the first insert should be the easiest way to get it to write correctly.

Is there anything in the log which says what has happened, like if the database is rejecting the data for having the wrong geometry type, or wrong coordinate system, or some other constraint on the table? Is there a trigger on the table checking geometries which is interfering?

Hi guys, thanks for those ideas. So far, I have tried everything what has been suggested, but couldn't find the error. But, I may have found something.

The data comes from a geopackage - I have created a simple flow only with a Reader and Writer. The Writer stores the features in the very same table. This way, the geometry is correctly stored in the AREA column, together with all the attributes.

So that would confirm that the table is correctly created and that the config of the Writer is correct.

However, if I use exactly the same Writer (Ctrl+C copied) in the original flow, it doesn't work, hence I guess the difference is in the data.

So, I have compared the features in the Data Inspector. Here's the feature from the simple flow one that works, just before the Writer:

This one is from a complex flow that doesn't work, again just before the Writer (identical by copying from the working flow):

In both cases, the geometry seems exactly the same, as far as I have seen. Obviously, there are new attributes that are not calculated in the simple (yet working) flow. I basically hardcode all calculated attributes in both Writers to keep it simple and to rule out any possible differences.

So unfortunately, I'm still unable to tell why that geometry doesn't get stored...

Thanks

@kcech​ in the second image you have oracle_type = oracle_nil try removing this attribute and see if that helps the format geometry type will usually overrule the fme geometry type.

Hi @Mark Stoakes​ , thank you, well spotted. How can I remove that attribute?

It is not visible neither in any Attribute* Transformer I have tried.

BTW, I see that it is created by an SQLExecutor against an Oracle non-spatial. Maybe it shouldn't be there at all? I have FME 2020.0.1.

Thanks!

Hi again,

I just found a way of removing the attribute. In BulkAttributeRemover, I put the expression oracle_*.

The geometries are being stored, yay!

I still don't understand why the SQLExecutor injects that attribute, it has the Oracle non-spatial Format. All I do there is to query a sequence and SYSDATE that I'll use in the Writer.

Thanks again Mark and everybody!