Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
nicolas_martin
Partner - Creator II
Partner - Creator II

Very huge ".shared" file

Hello,

I have a QV application of 1 GB on my server.

When I look at the ".shared" file, the file is about 4 GB!

Unfortunatly, this prevents me to access the properties of this application in the management console.

I don't understand why the ".shared" file is so big, whereas it should only contain bookmarks.

Can you tell me:

- what other data is stored in this file?

- how to prevend this?

- how to reduce the size of this ".shared file" without loosing all bookmarks?

Thank you.

Labels (1)
1 Solution

Accepted Solutions
korsikov
Partner - Specialist III
Partner - Specialist III

Also Using Inputfields will often lead to .shared files increasing in size

https://support.qlik.com/articles/000002629

View solution in original post

15 Replies
Gysbert_Wassenaar

The PowerTools 1.1 for QlikView contains a shared file viewer you can use to see what's stored in it.


talk is cheap, supply exceeds demand
nicolas_martin
Partner - Creator II
Partner - Creator II
Author

I can't open the file with the shared file viewer

I reduced it with the QVS.EXE command line --> now it's "only" 850 MB.

I still can't open the file in the shared file viewer.

After 1 hour, the shared file viewer showed me: 12 bookmarks. That's all!

2014-11-28_175506.png

I tried to log in the app, make few selections, change 1 "input field", close --> 1 GB.

The simple fact to change the input field cost me 150 MB in the ".shared" file!

Is there a way to say "don't save the values associated with the input fields"?

Gysbert_Wassenaar

Not as far as I know. The input field values are stored per user and meant to survive reloads. You could remove the .shared file, but that will remove all other server objects (like user-created bookmarks) for that document too.


talk is cheap, supply exceeds demand
ashfaq_haseeb
Champion III
Champion III

Hi,

Follow this to repair your .shared file in case they are corrupted.

Cleaning corrupt shared files

Regards

ASHFAQ

nicolas_martin
Partner - Creator II
Partner - Creator II
Author

My files are not corrupted.

The problem is that every bookmark (like "$LASTKNOWNSTATE") takes 80 MB, and the ".Shared" file is not automatically purged.

I don't understand why it takes 80 MB.

arieidel
Partner - Creator II
Partner - Creator II

Hello Nicolas,

I am also dealing with .Shared file so I understand you. I'm still looking at some solutions for a few issues...

With Shared File Viewer you can see the content of a bookmark, just double-clicking it and expanding it properties on "Bookmark" section, then expanding "FieldItems". These are fields stored inside the Bookmarks with their values. Suppose you have an attribute with 30.000 values. If a user selects a value from it and after that selects excluded values, a Bookmark with that selection will be stored with 29.999 values for that attribute increasing file size consequently.

Unfortunately, it happens. I believe that the only solutions is teaching users not to do that, but I know is a difficult achievement.

Regards,

Ariel

nicolas_martin
Partner - Creator II
Partner - Creator II
Author

When I look at my bookmarks in the "Shared File Viewer", I see that each bookmarks takes about 80'000'000 B (80 MB).

But when I export the bookmark (xml), the file is only few KB.

I don't understand what and where are the 80 MB of data...

vgutkovsky
Master II
Master II

Under the Tools menu in your screenshot above, select Defrag. The QlikView server does a very poor job of recovering unused bytes from shared files so a defrag becomes necessary from time to time.

Cheers,

Vlad

scottparry
Contributor
Contributor

Hi,

I've opened several QLIK tickets with no route cause as to why the .Shared file is growing so large in several of our applications.  Unfortunately, the powertools cannot read the .shared file and for the most part we are deleting .shared files daily now as size is increasing.

there is 1 input field, but we already tested that theory months ago, we changed it to a list box and the Shared file size was still growing after that implementation
I has become more unncessary maintenance to delete .shared files when you can't file the route cause.