Hi @Tty ,
Yes your sql example does make more sense now 
, although this could still be written differently to avoid a parameter within the main body of the sql if that causes problems.
Since in the WHERE clause, MONTH_NUMBER will always equal <MONTH_PARAMETER>, you can compare CUST_CLOSED_DATE with MONTH_NUMBER instead of the parameter value, e.g.
SELECT
MONTH_NUMBER,
COUNT(CUSTOMER_ID) AS ACTIVE_CUST_THIS_MONTH,
SUM(CASE
WHEN CUST_CLOSED_DATE = MONTH_NUMBER THEN 1
ELSE 0
END) AS CLOSURE_THIS_MONTH
FROM CUSTOMER_TABLE
WHERE
MONTH_NUMBER = <MONTH_PARAMETER>
AND CUSTOMER_STATUS = 'ACTIVE'
GROUP BY MONTH_NUMBER
I don’t know what limitations there are in the KNIME 3.7 nodes, and unfortunately I cannot install it side-by-side with my 4.3 version, but I’m assuming you’ve got what would now be the “legacy” versions of the nodes.
What occurs to me though, is if you are able to bring back your customers into KNIME, you could bring back the summarised data without parameters (or maybe restricted to the year-span that you are interested in),and then let KNIME do its stuff with nodes to derive the remaining information you require.
I assume your table must have other columns on it such as year; and it looks like “cust_closed_date” is also returning a month number, or else some translation is going to be required; but ignoring that, your query could be generalised as follows (without month parameter being supplied)
SELECT
MONTH_NUMBER,
COUNT(CUSTOMER_ID) AS ACTIVE_CUST_THIS_MONTH,
SUM(CASE
WHEN CUST_CLOSED_DATE = MONTH_NUMBER THEN 1
ELSE 0
END) AS CLOSURE_THIS_MONTH
FROM CUSTOMER_TABLE
WHERE
CUSTOMER_STATUS = 'ACTIVE'
GROUP BY MONTH_NUMBER
This would then bring you back the summarised table across all months. You could then process that returned summary table within KNIME, in a loop if necessary, to separate out the information for each month and do something with it maybe? That might be simpler than parameterising the query. That way you’ve also done a single round-trip to the database instead of repeated calls. Of course that might not fit your use case, but just a thought.
Depending on data volumes and other considerations, you could also just bring back the monthly snapshot table in (or at least a portion of it) and let KNIME do the summarising for you.
As a database developer myself, I have a tendency to want to do as much as possible “in the database”, and my mantra was always “cut down on network traffic: move as little data out of the database as possible” but times change, networks are faster, memory is more plentiful, machines are more powerful, and sometimes it is appropriate to move more of the the logic into the KNIME nodes, especially as it allows you to more easily prototype the manipulation of the result set.
So possibly some form of database reader node … I am using Knime 4.3 but both the Database Reader (legacy) and the DB Query Reader can do the same thing:
My (probably nonsensical) sample data:
… summarised result set that you could then act on with further nodes:
Realised that after typing out the code myself