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

Managing Bookmarks in New Applications

Hi All

We've recently successfully gone live with Qlikview across our business and our users are happily embracing bookmarks

We have a problem in that we are now going to have to tell our users that when we upload a new version of the app, they will loose all there bookmarks and will have to recreate them.

We have around 100 user bookmarks that this will effect and the only workaround we've found is suggesting that users email themselves a link with a bookmark, which they ca then use in the new application to recreate them (will be good to know if 1.) anyone has successfully done this before and 2.) if there is an easier and more seamless way of saving these down)

My main question however, is how do we prevent this from happening again?  I.e. how do we as a business create bookmarks that can be backed up and reapplied (or remain to exist) for the next application version? I've trawled the community and google but have not come up with a clear answer

We've so far steered away from Server bookmarks as this will quickly and easily become messy and hard to manage, whilst making it awkward for users to find their own...

I look forward to reading peoples thoughts

Thanks in advance

Rebekah

 

Labels (4)
1 Solution

Accepted Solutions
hartleyr
Contributor III
Contributor III
Author

Further to my last question and with the help of the answers posted on this question, I have managed to work out the detail on how to action this for our users.  For reference for others, these are instructions that I have published internally to carry out this task;

Qlikview Bookmarks are held within either a .Shared (original Shared file) or .TShared (Transactional Shared file – newer to later versions of Qlik and relevant to apps 2GB+).  These Shared files sit in the same location as the qlikview apps, and each Qlikview app has one associated 

When an app is updated, the .shared file is replaced, thus wiping any existing bookmarks out. 

To prevent removal of bookmarks, before an app is overwritten, we must first take a copy of the .(t)shared file for the current version of the app 

When the new app is in place, we then need to do one of two things; 

  1. If the shared file extension of the previous app matches the shared file version of the newest app, we can rename our copy to match that of our app and remove the shared file created as a result of the new app
  2. If the shared file extension of the previous app does not match the shared file version of the newest app (eold app has a .shared file, new app has a .tshared file), we need to convert the old shared file into the same version of the shared file used by the latest app. 
    1. Take a copy of the old shared file and save it to a test location
    2. Take a copy of the QVS.exe and save to the same test folder 
    3. Open the server and open the cmd
    4. Run the following in cmd; 

"<QVS test Location>\QVS.exe" -x "<Shared file test location>\<Shared File name>.Shared" -p -f tx 

  I.e. "D:\Qlikview\UserDocs\Development\Documents\Test\QVS.exe" -x "D:\Qlikview\UserDocs\Development\Documents\Test\TEST.QVW.Shared" -p -f tx 

 See - https://help.qlik.com/en-US/qlikview/November2017/Subsystems/Server/Content/QlikView-Server/QVSRM_Cl...1 for further detail.  

 3.  Navigate to the test location, take a copy of the cleaned file.  This can be identified by the '..._Cleaned' extension.  Rename the cleaned file by removing the '_Cleaned' from the extension name and apply this to your newest app

 

View solution in original post

7 Replies
Nicole-Smith

As long as you're not deleting the .SHARED file on the QV server, the bookmarks shouldn't be deleted.  That file is what contains everyone's bookmarks.

Brett_Bleess
Former Employee
Former Employee

Nicole is correct, but I wanted to comment regarding .TSHARED files, which arrived in November 2017/12.20 track, so depending upon what version you are running, you may be  seeing .TSHARED instead of .SHARED as Nicole noted, but she is correct in her statement, but there is another trick here as well.  If you have a 'sister' app that is the same data structure and visualizations, but a different file name etc., you can copy the shared/tshared file in those cases and simply rename it to match your new file and that should allow the users to still see things.  The last time I did some testing, even if you have a field that disappeared or a new field, I believe things should still work, those will just not be applied in those cases.

Hopefully this additional information may prove useful, but please be sure to do some testing to confirm you do see the same behavior as I have mentioned before doing things in production. 

Cheers,
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.
hartleyr
Contributor III
Contributor III
Author

Thanks both.  I'll give it a go and let you know how I get on.

Just to clarify, is it just a case that I publish the new version of the app, and just leave the 'Shared file' in place?  Historically, I've only replaced the app and not touched the shared files, yet we've still lost bookmarks, so maybe there is something more to it that I need to do...?

Cheers 

Rebekah

Brett_Bleess
Former Employee
Former Employee

Rebekah, just be sure the new version of the app has a matching file .shared/tshared.  The QVS will create one automatically, just FYI, so if it does not pick up the existing one, you may need to copy/paste/rename that to match etc.  Hopefully this makes a little sense.

Let me try an example too, App A is the original and App B is your new version, so what you want to do before you distribute the new version to QVS is copy App A's .shared/.tshared file and then paste the copy and rename to App B.shared/tshared, that way when you distribute, the app will already have the shared file there waiting for it, hopefully that helps things make a bit more sense. 

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.
hartleyr
Contributor III
Contributor III
Author

Hi Both

So, I have finally managed to start testing my new app with the 'shared' files, and I am running into some difficulties.

Can I ask what testing you completed? 

For some reason, my existing app, has a .Shared file and my new app has a .TShared file.  If I copy and rename my shared file over, it auto creates the TShared file that you warned me of.  If I copy the content from the .Shared to the .TShared file, I see no difference, however eventually, it appears the app rewrites over it anyway...

Any insight on offer would be greatly appreciated

 

Cheers

Rebekah

 

 

hartleyr
Contributor III
Contributor III
Author

Further to my last question and with the help of the answers posted on this question, I have managed to work out the detail on how to action this for our users.  For reference for others, these are instructions that I have published internally to carry out this task;

Qlikview Bookmarks are held within either a .Shared (original Shared file) or .TShared (Transactional Shared file – newer to later versions of Qlik and relevant to apps 2GB+).  These Shared files sit in the same location as the qlikview apps, and each Qlikview app has one associated 

When an app is updated, the .shared file is replaced, thus wiping any existing bookmarks out. 

To prevent removal of bookmarks, before an app is overwritten, we must first take a copy of the .(t)shared file for the current version of the app 

When the new app is in place, we then need to do one of two things; 

  1. If the shared file extension of the previous app matches the shared file version of the newest app, we can rename our copy to match that of our app and remove the shared file created as a result of the new app
  2. If the shared file extension of the previous app does not match the shared file version of the newest app (eold app has a .shared file, new app has a .tshared file), we need to convert the old shared file into the same version of the shared file used by the latest app. 
    1. Take a copy of the old shared file and save it to a test location
    2. Take a copy of the QVS.exe and save to the same test folder 
    3. Open the server and open the cmd
    4. Run the following in cmd; 

"<QVS test Location>\QVS.exe" -x "<Shared file test location>\<Shared File name>.Shared" -p -f tx 

  I.e. "D:\Qlikview\UserDocs\Development\Documents\Test\QVS.exe" -x "D:\Qlikview\UserDocs\Development\Documents\Test\TEST.QVW.Shared" -p -f tx 

 See - https://help.qlik.com/en-US/qlikview/November2017/Subsystems/Server/Content/QlikView-Server/QVSRM_Cl...1 for further detail.  

 3.  Navigate to the test location, take a copy of the cleaned file.  This can be identified by the '..._Cleaned' extension.  Rename the cleaned file by removing the '_Cleaned' from the extension name and apply this to your newest app

 

Josh_Berg_Support

Rebekah,

You can specify if you want the .SHARED file to be in TSHARED or SHARED file format by configuring the Settings.ini file for Qlikview server. The default location for the Settings.ini file for QlikView Server is C:\ProgramData\QlikTech\QlikViewServer.

Set the file format:
DefaultBlobDbType=0
With this setting, the .Shared format is used when creating new shared files.

DefaultBlobDbType=1
With this setting, the .TShared format is used when creating new shared files.

If you have the DefaultBlobDbType=1 any new shared file that gets created is going to be in TSHARED format.

Thanks,
Josh
To help users find verified answers, please don't forget to use the "Accept as Solution" button on any posts that helped you resolve your problem or question.