NPrinting 17 - dynamic field names

[kdmarkee]

I'm going to test this out but also want to post a discussion on it as well to see if anyone has any experience with this.  I'm wondering what would happen when an NP report executes but the column names in QlikView (or QlikSense for that matter) are dynamic in nature.  For example, let's say in QV you have a column that is built by piecing together the text "Dollars" and Year(Today()).  For 12 months the column name will remain the same, but once Jan of the next year rolls around the column name would change.  I am assuming NP will recognize this as a metadata change and not be able to execute the report until a Reload Metadata is done and report modifications done to reflect it...is that true?  If so, the work around of course will be to build static column names in QlikView/QlikSense and then use Formulas in NP report to make dynamic column header names to properly describe the column, while the underlying column data itself will use the static name from the QlikView/QlikSense doc (that is, no metadata changed).  Comments appreciated, but I'll also post my findings.  Thanks.

[Lech_Miszkiewicz]

Hi Kris,

Forget NPrinitng for a moment.

Could you please provide an example of QlikView object (table or chart) where your dynamic column would be used and how + reasons why is it easier for you to do this instead of having static column names

This is slightly different approach and i am trying to understand why would you use it instead of having this information (Year) as a value in one of the dimension columns.

Regarding the workaround - yes - it is exactly what i would have done.

regards

Lech

[kdmarkee]

A quick response on use case...

A use case for having dynamic column names would be so that we can use the same QV app for users to look at for analysis as well as for NP to leverage for reports.  Now, I have heard on more than one occasion in the Qlik Community that it is recommended to use separate apps for NP, however I find this frustrating because the flaw in this type of development is having to maintain multiple apps, unfortunately.

[pradosh_thakur]

Hi Kris,

Let me know if i understood this correctly.If you are talking about field names the yes i think without reloading metadata it may fail. If you are talking about chart level- column names(label) it is doable.

If you are talking about dynamic field name from script i have never tried it an not sure how possible that is and how hard to maintain.

regards

Pradosh

[kdmarkee]

Thanks for responding.  I'll now provide more detail and my test results.  By dynamic field I meant the label name (ie, ='Charges ' & $(vAccountingYearCur)) in my QV chart, so sorry for any confusion there.  So what was happening is that my report for Dec 2017 has "2017" in the QV label name but when I run Jan 2018 then "2018" is in the QV label name.  When I see the attached image below from my report in NP Designer, I immediately thought after reloading metadata (between 2017 and 2018 report runs), the report would fail because it wouldn't recognize the column name, however NP must acknowledge the underlying label name code vs the rendering/viewable label name because the report did not fail.  This was surprisingly good news, but I decided to make static label names in my QV chart anyway to avoid any confusion when looking in NP Designer.  Hope this info helps the community.

[pradosh_thakur · Accepted solution]

Hi Kris

I have been using functions(getfieldselections().year(today()) etc ..) is label name and it seems to work just fine. I have been using this for long and i dont remember having any complains about it. May be it's my good luck.

What if you not use the dollar sign in the label name. If it still works and gives you a formulae, i Think you should be good. Do cross check before you go live.

regards

Pradosh

[kdmarkee]

I agree, no issue.  Yes, my report works fine as well if I leave the variable in place for QV chart expression label.    I opted to change my QV chart label to a static one though just to avoid any confusion when viewing the fields as they are seen in NP Designer  For example, in my case "2017" is seen in NP Designer because that is what it was when I first loaded the NP connection and built my report, but this could be confusing for report scenarios where the year is not 2017...it is merely serving as clear "documentation" so to speak.

[Lech_Miszkiewicz]

I got fixed up thinking that you were referring to column names in data model (not table header labels). In this case it is all good!

cheers

Lech