Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
We use QlikView Desktop for our Apps (not server). We host the Apps on a LAN in London. The guys in the London office have quick response, we in Leeds have really slow responses. For example it takes them 6 seconds to open a 900Kb (that is kilobytes not megabytes) and it takes us 3 1/2 minutes. However if I reduce the number of sheets in the qvw from 20 down to 1 it reduces the time it takes to load dramatically even though the size remains more or less the same. It does not take 3 1/2 minutes to open other file types over the LAN.
Also navigating through an Document opened from the LAN compared to one opened from my C drive is very slow. This is suggesting that the Document even once opened is constantly reading/writing to the Network.
Does anyone know anything about what's going on? Yes I understand the Network is slow but why does it affect QlikView so badly? Why is QlikView so slow even after it is opened?
as a test I removed all on open triggers.
266kb file took 1 mins 27 secs to open with triggers. same file took 1 min to open without triggers.
The same file opened locally takes about 4 seconds.
The network is not that slow. For example I can copy/paste in a few seconds. So it's something in the way the QlikView communicates with the Disk.
I did previous tests and if I remember correctly the thing that had the biggest impact on opening speed was the number of sheets in a qvw.
Hey Shane, if you are current on maintenance, I think I would recommend you go ahead and open a support case at this point, if you can attach one of the qvw files that is giving you trouble, we can have a closer look at things to see if we can spot something to give you a better idea of where things may be. Obviously the OnOpen has an impact, but it does not explain everything unfortunately... If you do open a case, feel free to send me a private message via Community here with the case number, that way I can go have a look at things...
Cheers,
Brett
Yes, it sounds weird but I think there are a lot of possibilities which might cause such strange issue.
At first I would also think on any security tools / policies which may had identified the application as a network/internet file (similar to the way Windows handled files which are downloaded from the internet or from outlook) and now a heuristic routine checked every change in the RAM or the interactions with the OS and/or QlikView runs then in a kind of a sandbox or something similar. Normally your IT should be able to shed light in way they had implemented their security. A check without further information is surely not easy but I could imagine that by a close monitoring of the processes in the task/resourcen/performance manager and the various log-files should give some hints what's happening (in beforehand switch off everything what's possible, various auto-starts, print-driver and so on to reduce the amount of data).
On the Qlik side I suggest to check if there are prj-folders for those applications. Also does shared-files exists - even if you used the qvw's only with the desktop client the may exists (if there is or was any server usage of them) and also contain server-objects or maybe even extensions. Further a look on the used releases of QlikView may be helpful because it might results in any incompatibility.
Another thought goes to data and expressions in the application itself. Are there any document-related functions in use, like documentpath() or the direct discovery feature. Further is there any section access in use. All of them may not completely work and leading to invalid expressions or calculations over loosen tables or similar.
Further were there any changes within the easter egg like enabling the extended logging or macro-functions? In general it would be useful to check the user-properties to various settings, like the various paths, auto-saving, mail-settings (any alerts enabled?) and so on ...
Some of the above mentioned things seems to be quite unlikely but I would exclude them one after another - just to be sure. Good luck.
- Marcus
After some testing we've identified the issue as being text boxes linking to 7 icons and 1 logo - all png's totaling about 75kb in size. Working from home (not in office) it took 7 minutes to open a 1.5Mb qvw; then the same qvw but the images replaced with webdings, windings and plain text took 15 seconds to open.
No idea why the big difference in performance but at least getting closer to what specifically in out qvw's is slow.
How are the png-pictures implemented - as image within the textbox or as background-image?
AFAIK is it implemented as background-image the picture will be embedded within the qvw and is it an image in the textbox it just stored the path to the file and pulled it by each opening and if the path is an expression or a variable the pulling of the image might be triggered more often. Is the last the case then it's probably not the file-size which caused the delay else the number of calls and from a security tool point of view it might look that an application is loading code from a public network and scanned it each time.
- Marcus
They're as text boxes. Embedded are no good because they will not resize. Thanks for the info. Will feed it back to our Network guys.
I'm not sure if my last answer was clear enough - with background-image I mean a background-image in the textbox and not in the sheet. AFAIK you could position and resize them (respectivelly the textbox) like the picture is shown in the content-area of the textbox.
- Marcus
I might test this but if memory serves me correctly they didn't resize well to different screen resolutions. Or perhaps the resolution of the image because blurry. But the biggest disadvantage is that we change the "logo.png" to be specific to a client, so if it's an external file it's as simple as replacing the png if it's embedded it's a lot of work as we have a suite of Apps not just 1 qvw.
I'm not absolutely sure but I believe there is no essential difference in sizing and resolution between both ways to display pictures.
Beside this I assume that your way to provide the path is a combination of fixed text and one or more variables which change their value depending on the documentname() or something similar. I never really test it (it's probably quite difficult) but I could imagine that the variable and/or the expressions within it trigger the path-evaluation quite often and may therefore delay everything quite significantly (in a not suitable environment).
Depending on your requirements it might be just solved with multiple textboxes - each one with it's own picture - and then the visibility of the textbox is controlled with your logic. If there are more strict restrictions the visibility might be also controlled through a section access (I assume there is already one to restrict the data within the application).
A further option could be to load the pictures into the qvw: Loading-Images-into-QlikView.
- Marcus
Actually it's much simpler than that. We have a path:
..\..\SYS\_Images\logo.png
and when we roll-out our tool to a new client we replace the logo.png hence customising all qvw's by one simple action.