Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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
Hello, Frank!
You can use a developer table for checking count of repeated fields (which may be reason of cyclic reference).
Just like this:
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.
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?
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...