SQLSERVER Reader type generates unnecessary warnings

I can just add that this is a fairly common request with our clients: they want to get rid of warnings that aren’t important to their process, so that “real” warnings get better visibility in the Flow jobs overview.

So far I’ve only managed to remove certain warnings by introducing transformers specifically to get rid of them (e.g. CoordinateSystemRemover, Decelerator, BulkAttributeRemover, etc...) but I find it unsightly and it complexifies the workspace for no good reason.

It would be fantastic if there was a way to ignore known warnings (using wildcards?) on a per-workspace basis.

Agreed. It would improve my jobs-dashboard tremendously. I know in my dashboard I could get the logfile, parse it, and filter out these warnings, but that would slow the dashboard down...

To be honest, I don’t even understand why this particular one (“does not include a spatial column. Geometry will not be read”) has to be a warning at all. Information maybe, but even then: I wrote that SQL statement that the transformer has to execute myself, so I know there’s no geometry in the select. Why should that be a warning? It’s my own doing! It makes no sense to me in this case...

Fully agree. 

I recently had a case where the Clipper gave a warning about being unable to use 0 for tolerance and that it had calculated a different value. The problem was that this older version of the Clipper didn’t even have the tolerance setting! The solution was to update the Clipper and make sure the tolerance was set to automatic, and just hope that all the new settings that were introduced didn’t change the result.

There’s lots more that have cropped up from 2024 onwards

“Resetting a database that is still referenced”

“No query delimiter specified; SQL will be treated as a single statement. To specify the delimiter token, write FME_SQL_DELIMITER <token> as the first line of SQL text”

Warning message: Resetting a database that is still referenced. | Community

Oh yes, the no-query-delimiter one. I’ve got some quite complicated sql’s, using CTE’s and unions - that one always crops up with those kinds of statements. 

Never encountered the resettng-database one though, at least not that I remember.

But the spatial column one only started showing after the introduction of the single SQLSERVER reader-type, so that is fairly recent. The no-query-delimiter I’ve seen for a looong time, if memory serves me right I’ve already encountered that one when still using 2014. 

Something else I just noticed (because the scheduled workspaces all failed!) with the new combined SQL Server type, is that automatically a geometry column is added to the Writer configuration. I have a lot of workspaces that do NOT write any geometry, but yesterday a bunch of them failed because

“Spatial Column ‘GEOM’ with type ‘geometry’ does not exist in table ‘<tablename>’.” 

Due to the fact that this configuration is only shown on the User Attributes tab, it is extremely easy to miss, also because it does not show a red triangle when you feed it features without geometry. 

I am less and less convinced upgrading was a good idea, tbh...

Hi folks! Thank you for bringing this to our attention.

I can see how filtering warnings and log files would be helpful in debugging. It’s a great idea and I’d encourage you to Submit an Idea if you haven’t already 😄

Besides that, the jobs failing and that warning message is worth looking into ​@s.jager! We’d love to dig into this a bit more, particularly the upgrade process you took with these workspaces. It would help us better understand the underlying issue and improvements that could be made. 

If you prefer, and if you haven’t already, you can also submit a support ticket with us


[internal: FMEENGINE-89051]

The upgrade process is fairly easy: right-mouse-click on the writer in the Navigator, and select Update Writer/Reader.

You then get for the database connection only one choice, when there used to be two: a Spatial one and a Non-Spatial one. Since the merge of those two, FME automatically assumes geometry, on every single table - and I frequently deal with objects that have no geometry. On all reading transformers that generates the warning from my first post, on writers it generates the warning from my previous post in this thread - and with the writers, it fails the translations. on the readers it just messes up my dashboards, because I get 5000 warnings that my statement does not include a spatial column, and that therefore no geometry will be read…. No shit Sherlock! But just on the off chance that warning 3475 is actually a warning that I need to do something about, I still have to check them… I might actually invest the time in letting FME do that for me ….

OK, this one just got more annoying: Added a Writer in order to delete a bunch of duplicate rows from my table. Feature Operation is set to Delete, Table Handling is set to Use Existing, Match Columns is set to the Primary Key of that table (and since I do a select * from that same table, I am guaranteed of that PK-column having a unique value). So when trying to run, the workspace fails, with this error message:

Why? First of all these are rows from a join-table without any geometry, secondly: the Feature Operation is set to Delete. How does that warrant a check on a geometry column being there or not? All that matters is whether the Match-column is there or not.