Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi All,
I am about to recreate a QV app in QS. Every official post tell that QS is better than QV.
But when I try to remake a simple table in QS I face serious barriers... Basic set of charts in QS are way less customizable then charts in QV.
There is a variable and a table in QV. They are linked with each other somehow (I am not sure how and where it is set): when I select a date using that variable (for which you can easily set a calendar input format - neither this format setting is possible in QlikSense) the content of the table changes accordingly - filtering the content properly: showing only the proper of the proper field (and the rest of the fields in the data model).
However, there is no actual field selection - nothing shows up in the current selections panel - it works smoothly (in QS it seems that it takes thousand times slower (providing "calculation timed-out" type errors) as there is no way to pre-filter the content using an "external" variable AND avoiding to set unwanted filter on any field at the same time. If I filter the date field then QS calculates everything as fast as QV does without filtering that certain field (but I guess it runs on less data thanks to the linkage between the variable and the field)... Yet, I do hope there is a way in QS to avoid field filtering...
How could this be remade in QS? As far as I learned there is no such variable which could work as a replacement for the one used in QV...
If I link a variable to a field in QS then using that variable results a filter in that particular field to which the variable is linked - BUT this is something I need to avoid.
My so-far-best "solution" is: making a separate dateselection field (not linked with data model) linking it directly with the variable and then referring to its value in a set analysis: {<[datefield] =P([separate_dateselection_field])>}. I have used this with Aggr() in the dimension's expression). This "solution" results calculation timed-out errors too many times, and it is way too slow (in case it actually succeeds to calculate everything)...
Please help me with any idea, workaround, etc.
Thanks,
Levente
I do agree that QlikView and Qlik Sense aren't the same and that not everything in Sense is better and/or more useful/practically.
I don't know if and when field/variables-triggers will be a native part of Qlik Sense or if there are already any extensions which could be used for it. IMO they are not necessary within the most scenarios because quite often could the same or even a better usability be reached without all this magic-stuff - see here what is meant: Macros are Bad - Qlik Community - 1466215.
The only triggers which we have in use within the normal reporting are OnOpen-triggers to set a certain selection - usually the current period or to apply a bookmark.
In your scenario I wouldn't use variables else selections of the date-field direct or a duplicated field from it or here more likely from an island-table. You could consider the island-tables as a variable, too but IMO they are much more flexible and powerful because you could have multiple fields here and/or also integrating as-of-table logics. By using hideprefix or tagging the fields as system or hidden they won't be shown by the selected fields and especially by using p() within the set analysis the control of the regarded dataset is quite easy.
- Marcus
I think you need to comprehend the applied logic from QlikView before you could handle any struggles respectively differences of it in Qlik Sense.
If I had to solve this task I would at first look if the variable is really a variable and if it triggers any action/macro. If there are some you will see which actions they do - most likely would be a selection to a (per hide-prefix) hidden field.
If there is nothing obvious I would compare the data-model - are really all tables and fields there and properly associated, have the tables the same number of records and have the relevant fields the expected values. There are lots of possibilities that quite small differences in the data-interpretation and/or the load-script and/or the executing user/machines could cause bigger impacts.
- Marcus
Hi Marcus,
Thanks for your kind response. I have actually copied the code from QV to QS. This shall not be the root cause.
The other thing you mentioned was to check if the variable was really a variable, etc. It is a variable, or more precisely, it gives value to a variable. And unfortunately there is no clear sign of any "outer" connection in the settings panel (ie macro).
Using that front-end visualisation item I can simply add a value to the variable. Making it in QV on the same data means no issue - it runs smoothly. What is important that it does NO FILTER on the data model. I am sure, becasue it would be clearly recognized on the other sheets where trend is displayed instead - not only a singe day's data (which is the aim on the initial page). We want to see details of current (or preferred date's) status and there are other sheets where we can monitor overall trend of certain KPI.
Above screenshot is from QV. I do not know how could I assure that there is no any automation initialized by setting any value on this object.
I do not know what does "Override Locked Field" checkbox mean? Why is it not editable?
Presentation - Sort - Number - Font - Layout - Caption: these are the further tabs where additional settings can be made, but I am sure that there is nothing automation related on these tabs.
In QV it is somehow enough to put down a simple table with simply adding the required dimension (no aggr() or any other fancy stuff) and using that date selection panel the table's content changes accordingly.
In QS the closest equivalent solution is the one I described in my initial post. I am so disappointed that there are still huge deficiencies in QS comparing to QV. I wish I could understand why is it so? If Qlik could do something many years ago in QV how come that it is still not possible in QS?
Anyway, thanks again for you kind response. I continue digging the web trying to find some solution to be able to reproduce the old QV report in QS...
Levente
Important is to identify if changing the variable-value impacts the dataset - you may check with other objects on other sheets - or if it has only an effect on certain objects. If the available dataset respectively the rows within a table-box increased/decreased any selection is applied. If this doesn't happens and only some objects react it means that there are any conditions within expressions - this must not only be the normal measures else all calculations in title, labels, colours, sorting, visibilities and so on could be related.
To look for any magic go to the document properties in tab triggers and look there for all fields + variables + document triggers if there is anything applied. The final action must not mandatory come from this variable or the underlying field else the selection could be a side-effect from another evaluation. Helpful may be also to look within the macro-editor (ctrl + M) if there exists anything.
Another thought goes to alternate states which could also have an impact. Therefore a check if the objects/sheets are in any alternate state might be also useful.
Like above already mentioned the loaded dataset might have also an influence. Copying the script and executing a reload doesn't mean mandatory that the identically dataset is created. Depending on various factors there could be differences how the data are loaded and/or interpreted.
- Marcus
Hi Marcus,
Thanks for the valuable info.
It already answered some of my questions regarding the old QV app, unfortunately not the one I posted above, but raised my attention to a next challenge coming ahead (as far as I know there is no field event trigger funcionality in QS yet)...
Setting the variable's value has no effect on data model - only some charts react faster.
I have just found a comprehensive comparison summary between QS and QV which makes me feel that QS is not a true heir of QV (still there is an official incentive to convince QV customers to change from "old" QV to "new" QS)... They are not purely "old" and "new" they are rather "A" and "B" (yet), aren't they? They have pretty much in common which make it possible that you can transform your QV app to QS, but the differences sometimes are so significant (yet), that you simply can not recreate the same app in the same quality in QS...
I have also found a community page (hosted by Vislib support) where someone faces the same issue and requests some help stating that "QlikView allows you to use Dimensions or Variables as the "Date Field""...
Then the problem is further detailed: "Variables are cleaner as they're not treated as selections that show across all sheets and will not affect all objects. We explicitly want the date picker to only be relevant on a single sheet or defined objects, which variables can do since they're explicitly referred to in expressions/measures. Allowing Variables as the "Date Field" would accomplish this." - This seems to be exactly the same challenge that I face during this transition from QV to QS regarding my given app.
Finally, let me quote what you wrote: "Copying the script and executing a reload doesn't mean mandatory that the identically dataset is created. Depending on various factors there could be differences how the data are loaded and/or interpreted." You see, this is pretty much confusing for me... How could that happen that same dataconnection & same dataload script results any difference in datamodel depending on you use QV or QS?
Could you please just name some of those factors?
Do you know if any time in the future QS also has the functionalities like Field Event Triggers and Variable Event Triggers?
Levente
I do agree that QlikView and Qlik Sense aren't the same and that not everything in Sense is better and/or more useful/practically.
I don't know if and when field/variables-triggers will be a native part of Qlik Sense or if there are already any extensions which could be used for it. IMO they are not necessary within the most scenarios because quite often could the same or even a better usability be reached without all this magic-stuff - see here what is meant: Macros are Bad - Qlik Community - 1466215.
The only triggers which we have in use within the normal reporting are OnOpen-triggers to set a certain selection - usually the current period or to apply a bookmark.
In your scenario I wouldn't use variables else selections of the date-field direct or a duplicated field from it or here more likely from an island-table. You could consider the island-tables as a variable, too but IMO they are much more flexible and powerful because you could have multiple fields here and/or also integrating as-of-table logics. By using hideprefix or tagging the fields as system or hidden they won't be shown by the selected fields and especially by using p() within the set analysis the control of the regarded dataset is quite easy.
- Marcus
Hi Marcus,
Thanks for this eye-opener post. I laughed aloud on the last line: "Macros are Bad, but Triggers are Worse"...
Well, in this case, I am a bit desperate about my chances to come out good from this challenge to recreate that certain QV app in QS.
What you suggested (island dimension used in set analysis with P()), well I guess this is exactly the way (I have called it "my so-far-best solution") I hoped QS would be able to calculate everything smoothly, but sadly, that did not work...
I am about to realize that there is a big chance that I shall either somehow manage to get customer's buy-in of changed way of operation (which might not be a smooth one), or I should reengineer the whole app to ensure that customer gets the same (very similar) quality in a different way. It would be still a change for them for some extent, but at least it could result more straightforward and user-friendly logic. The funny thing is that I am not sure if I have that much time...
My biggest fear is that the QS verison will be quite jerky - requiring users to filter in and out date fields depending on which sheet they use at a certain moment...
Levente