Skip to main content

Hi,

 

I have a bunch of fairly complicated SQL queries, which I frequently use in an SQL Creator. This saves me a tremendous amount of featuremergers and such, because the sql basically re-creates the business object from the normalized database tables. Up to version 2020 this worked just fine: insert an SQLCreator, select DB Connection (SQL Server 2016 SP3), copy-and-paste SQL from my code snippets, click on the ellipsis to Expose attributes, click on Populate from SQL Query, and I'd be done.

 

Now that we've upgraded to 2022, that does not work anymore. The Attributes to Expose dialog stays empty, and no error messages or warnings appear in the log. It is rather annoying because I have to do this all the time, and now I have to copy the attribute names manually from my sql statement. It's causing me quite a bit of extra work.

 

Am I missing something? I am currently using FME(R) 2022.2.6.0 (20230523 - Build 22800 - WIN64) , and up to now this method has always worked just fine, no matter how complicated the sql (comments could sometimes cause a problem, but with-clauses, joins, where-clauses never were a problem). But now, with that selection of Schema, Schema&Data, Data selector, this does not work anymore.

 

TIA,

Stefan

 

Hmm, it works ok for me. I did find though that I needed to make sure I wasn't using any @values in the call but that makes sense.

 

I'm on FME 2022.2.5

 

 


As an alternative, use an AttributeExposer downstream and choose Import From Feature Cache.


I'm not using any @ values or specific SQL Server dialect, it is plain ANSI SQL. Sometimes I use a value from a parameter, but that has never been a problem (just replace it with a value when exposing attributes, and it works just fine).

 

AttributeExposer is indeed a solution, but it is also a workaround for something that used to work perfectly - and is very convenient to use (when it works 😉 ). For now I guess I'll resort to doing that...


Update: It seems that the With-clause is causing the problem. If I take that out, then it actually works. My biggest beef is, that this has worked in 2020... I've always used this, and it saves a lot of featuremergers, transformers, memory use, performance etc if I let the database do most of the work...


Reply