Our users' bookmarks disappeared twice in a year for no reason

[kyan2017]

For some reasons, our users' bookmarks got lost twice in a year. First we thought whenever we update QlikView, the bookmarks will be dropped off. I did several test on Dev by creating several bookmarks and did update of the QlikView by changing the listbox display numbers and adding charts columns, etc. After the changes above, I reloaded the application, but my bookmarks were still there.  Couldn't figure out a reason what caused the bookmarks gone.

Also, if the reason is the update of the QlikView, it shouldn't only happen twice in a year, because I did more than twice of the update.

Could anyone help me with this? What will be the reasons that can cause the bookmarks gone?  If we know the reason, we can prevent this happen again in the future.

Thank you so much for your time and patience!

Kexia Yan

[Miguel_Angel_Baeyens]

User bookmarks, as well as any other user created content by means of the Ajax client is stored into .Shared (or .TShared) files which are located in the same folder where the QVW is.

If those files are corrupted or deleted, or not copied from an old server to a new one, all such contents will be lost.

First check that those files exists and that they are modified (and their size likely growing) whenever you add a new bookmark.

See more details here:

• https://support.qlik.com/articles/000003825
• https://help.qlik.com/en-US/qlikview/April2020/Subsystems/Server/Content/QV_Server/QlikView-Server/Q...

[kyan2017]

Thank you Miguel.

But Why or How the shared file is corrupted? We didn't deleted the file and not copy from old server to new server....

Thank you again!

[Miguel_Angel_Baeyens]

First of all, they shouldn't get corrupted.

However, like any file which can be accessed by several resources (QlikView, antivirus, backup, others) and which can be under high concurrency (depending on QMC configuration, Shared files are -not exactly but roughly speaking- open, locked, read, written, closed and unlocked every time a user clicks anywhere on the QlikView app), deadlocks happen and corruption happens.

Of course, the bigger the file it is (if there are hundreds of users in the environment and the app is complex with many sheets and charts, if users are allowed to create their own objects using the Ajax client, if Session Recovery is enabled and the Shared file is never cleaned up, it will only keep growing and growing) the longer it will take to be open, read, written and closed again, and the likelier it will be for deadlocks to happen.

A proper investigation on why this happens needs to be performed as it could affect any other file in the file system (like QVDs or QVWs, although these files are not open as often).

[kyan2017]

Thank you Miguel! We never pay much attention to the shared file before. So I am guessing from now on, we will have to backup this file often or maybe daily? in case this will happen again in the future.

[kyan2017]

By the way, if I only modify a chart format and then save it and reload the app successfully, will this cause the same issue?

Thank you again!

[Miguel_Angel_Baeyens · Accepted solution]

No, Shared files are modified by interacting with the Ajax client. If you open a QVW with QlikView Desktop, reload it (or using the QMC) and save it will not modify its Shared file.

And to your previous questions, again, backing them up will depend on their contents and their criticality. I would argue that user created bookmarks must be backed up since they can be very easily recreated. Same with enabling Session Recovery.

However, if users are creating their own sheets and objects, backing up the Shared files is something to consider, bearing in mind that, generally speaking, a Shared file can only grow if it's not purged regularly using the qvs.exe tools mentioned in the links above.