Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Normally, noconcatenate is used override qlik default behaviour when table structures match.
Are there any issues (performance or otherwise) with adding noconcatenate to every load even when the structures don't match?
Our developer in this case is just a novice. Its just confusing to support this because when I see noconcatenate, the first thing I look for is which table has the same structure.
As much as the 'auto-concatenate' feature tries to be helpful, many a development session has been blasted away as puzzled developers try to figure out "what happened to my table?!"
Such as a tricky situation like placeholders. If there's no performance hit for using NOCONCATENATE I wouldn't be too hard on them (in a defensive programming world, are they doing any harm?).
[PLACEHOLDER_FOR_TABLE_1]:
LOAD 1 AS ID AUTOGENERATE (0);
//.....some scripting later //
[PLACEHOLDER_FOR_TABLE_2]:
LOAD 1 AS ID AUTOGENERATE (0);
//** What happened to my second target table?!
I've had "clever" experiences where when auto-concatenate is in effect, a seeming innocuous later date change subtlely aligns two formerly disparate table structures into a unified one and results in unintended auto-concatenation never meant to be such, and becomes a big headache.
Be cautious when presented with the innocent request (many months later) for "would itttt be hard to rename this one field from [BlaBla] to [BlablaBla]?" You might be getting set-up.