topic Re: Nocontenate every load in QlikView

Nocontenate every load

markp201 — Sat, 16 Nov 2024 04:51:30 GMT

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?

Re: Nocontenate every load

dplr-rn — Thu, 03 Jan 2019 14:31:31 GMT

Why do you want to do that?
I wouldnt assume there will be much of overhead as far as running the script is concerned. unless there is multicolumn synthetic keys

Re: Nocontenate every load

markp201 — Thu, 03 Jan 2019 15:00:08 GMT

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.

Re: Nocontenate every load

evan_kurowski — Thu, 03 Jan 2019 15:35:29 GMT

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.