Skip to main content
Announcements
Qlik Connect 2024! Seize endless possibilities! LEARN MORE
cancel
Showing results for 
Search instead for 
Did you mean: 
Pudding
Partner - Contributor
Partner - Contributor

Is there a way to completely stop the shared file from being created?

Hi all! I have had major performance issues with my Qlikview document.

We have a dashboard that keeps track of client statistics. How long do they take to pay, for example. If they take too long to pay, something in the dashboard starts screaming (well not really screaming but an alert goes off). Then the account manager has to look at the alert and see if they can explain why the alert went off (1. The client is dying 2. The client is a fraud 3. The client is on holiday and will pay when he returns). This explanation they put into a “input box” in Qlikview, which is just a button that executes a macro through the Qlikview Plugin of Internet Explorer (meaning we do not use the AJAX client). We use the AccessPoint and have a userbase of anywhere from 5-30 people online at once using this AccessPoint.

The dashboard is slow, crashes and gives black screens when more than 5-10 users are online. We have isolated the issue to the shared file. It grows extremely big extremely fast. Now we have resorted to delete the shared file every 5 minutes, but the business still has the same performance issues. We are pretty sure the shared file is the problem, though. We see that every time a user adds a comment (executes the macro) the shared file grows significantly and using PowerTools we see the shared file only consisting of comment-related stuff.

(TL;DR que here) Basically my question is: Is there a way to completely stop the shared file from being created and do you think this is a good solution?

3 Replies
marcus_sommer

What do you mean by "growing extremely big and extremely fast"? How many entries are there and how big becomes the shared file in this time?

Personally I wouldn't expect that the shared file is already exploding in 5 minutes with just a few users which probably need some time to check each case before entering anything - means it shouldn't happen very frequently. Therefore I could imagine that the real cause might be an unsuitable datamodel - means the entry isn't just an entry else it will be assigned to n records of a fact-table and this could of course become quite heavy - and/or your macro(s) are triggered more often as needed.

I'm not sure if you could get really a stable and performant solution with such a DIY approach. Many years ago I tried to develop a planning-tool with QV with multiple inputfields / inputboxes and a lot of macros and the efforts was amazing expensive to get it partly stable and it didn't contain much data. Nobody want it - until today they love their easy to manipulate Excel file ... Nowadays I wouldn't go this way again - else I would consider / recommend to use an appropriate extension to write back data (AFAIK there are various available) and even if they cost some money it's cheaper as developing it at your own.

Beside this you mentioned only shared-files - the newer releases of QV have this feature upgraded to Tshared-files which shall run more stable and performant - maybe it's an option for you.

Also you could try to disable respectively to reduce the amount of the shared-files within the document-properties in tab server and/or also within the qmc by documents and server objects.

- Marcus

Brett_Bleess
Former Employee
Former Employee

The shared file is where all the user/server objects are written, so no, there is no way to turn things off, and I can safely say if you are deleting the shared file on-the-fly, you are making matters far worse, as you have to remember the QVS keeps a lot in memory, so when you are deleting the file, it is going to just recreate from memory, but that is also likely going to cause memory corruption eventually too.  If you want to delete a shared file, you need to stop the QVS service, then delete and then restart the QVS service, doing any other way is risking corruption of the environment.  

The check the QVS settings in the QMC, in particular the Document tab settings, be sure Allow Session Recovery is not checked, that creates a lastknownstate bookmark and updates every time a user exists their session, shutting that off will mean the user always starts at the default page.  You will want to turn that off, then delete the shared file to clear any lastknownstate/session recovery bookmarks.  You can also uncheck the Allow Server Objects, which will only allow normal user/server bookmarks which should not be a huge issue.  If you are running a release that supports the tshared file format, I would also recommend you enable those too.  

About the best advice I can offer, here is a link to shared file help that will come in handy regarding cleaning the file etc. if you want to try that too.

https://help.qlik.com/en-US/qlikview/April2019/Subsystems/Server/Content/QV_Server/QlikView-Server/Q...

Shout if you have further questions.

Regards,
Brett

To help users find verified answers, please do not forget to use the "Accept as Solution" button on any post(s) that helped you resolve your problem or question.
I now work a compressed schedule, Tuesday, Wednesday and Thursday, so those will be the days I will reply to any follow-up posts.
rwunderlich
Partner Ambassador/MVP
Partner Ambassador/MVP

Are you using an InputField to store your comment?  When an InputField is used, QV uses a space for every possible InputField value (by unique key).  So if you have an InputField linked to OrderId, and you have 10M Orderids, each user will have an array of 10M values in the shared file even if they only comment on one OrderId. 

Are you using .shared or .tshared file? Switching to .tshared will not fix fix the space issue but it may fix the stability problem.

(BTW, I haven't tested to see if the .tshared reserves the same space).

-Rob
http://masterssummit.com
http://qlikviewcookbook.com
http://www.easyqlik.com