Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
frank_dehner
Contributor II
Contributor II

How to detect cyclic references during script run?

Hi,

We got an unexplainable memory overflow on QlikViewServer. After some investigation we found that a special qvw file caused this behavior. The reason was a cyclic reference driven by modified data that were loaded via Generic Load. It happend that one of the fields generated by the Generic Load was already present in the data model. We got the cyclic reference! The first user who tried to open the report in access point caused the same problem again with consuming memory till the limit...

My question: Is there any way to detect during script run that a cyclic reference occurs? I know that we can minimize the risk by renaming or qualifying the fields. When I run the script locally on my computer I get an explicit warning message if a cyclic reference occurs but I cannot see any kind of hint in the script log file on the server.

Thanks a lot for your answers.

Frank

2 Replies
Sergey_Shuklin
Specialist
Specialist

Hello, Frank!

You can use a developer table for checking count of repeated fields (which may be reason of cyclic reference).

Just like this:

pic_synt.png

Use $Field system field for calculating the count of crossed fields.

And if you don't want to load all data you can use Debug Load in the script and restrict the number of loaded rows to 10.

frank_dehner
Contributor II
Contributor II
Author

Hi Sergey,

Many thanks for your suggestion. Unfortunately it will not solve my problem because the system fields are not available during script run. In my case nobody can open the report because the cyclic reference causes immediately an endless opening with full memory consumption.

But your idea drove me to think about a way to detect unexpected references in generally. I see two points where we can access (at the very end of the script):

a) We can detect unexpected references and

b) We can detect synthetic keys.

[Normally we take care to prevent both thinks during development but via Generic LOAD or LOAD * from any data source we can still get unexpected "dynamic" fields...]

How to do?

  • It is easy with two loops to get all tables and all fields.
  • We can count the occurrence of each field to detect key fields (count > 1).
  • If we follow "best practice hints" all of our expected key fields are marked with a special prefix, e.g. "@"
  • --> We can search for key fields w/o such a prefix and can place some crash code there to prevent successful script reload.

Detection of synthetic key is a little bit difficult. We have to find all table links with more than one field and can do the same crash there...