Thanks for your reply.
I'm afraid that wouldn't solve the problem. We need to secure the server with a user ID and Password so that no body would have access to the server. but at the same time we need to reload our application using the qvds that are residing in a password protected server!
Any other idea?
Why not schedule a windows task to reload a single qlikview from the command line then have the users pick up the qvw from there but...
If the QVW is stored locally on the users' machine how do you ensure the security of those workstations. If they are laptops I think you'd be in a bigger bind if security is that important. In the QVW the data is translated and structured for use while a QVD would require some knowledge to use, so it is unlikely that you will have somebody looking at a QVD simply out of curiosity
Bottom line, if security is so important your should just buy the server, SBE is very affordable and probably would cost you less in the long run, savings in Risk and Effort would be very valulabe.
All the users have laptops and they are encrypted! so the user's systems are secured.
I agree what you are saying but they dont want to buy SBE. Not sure why. I wish with QlikView we could make password protected QVD files.
Like when we have to connect to a database we have to provide userID and Pass, I wish there was a way to do the same with QVD files!
Cant we do something with Macros or some sort of scripting here?
I really didnt understand the criticality involved.
For the VM Server you can have what ever the user id and pwd you want, but other users to access any files you should give them sharing based on user nt id.
Once you have given access to the users based on their nt id no other user is able to access the QVD's unless they are given access.
Once listed userts have given access to the QVD folder they can simply reload the applications residing on their PC by pointing to QVd on the virtual server using the path notation \\servername\foldername\abc.qvd.
Please see the simplifed file pointing snapshot as attached.
Please let me know where did u stuck, what is the error.
SharedQVdfolder.PNG 12.2 K
I would suggest setting up an odbc connection on each laptop and then connect to it in your load scripts. It will pass an encrypted username/password along that the users won't be prompted for when they hit reload (it is stored in the load script as an encrypted string so it is not easily identified).
Then rather than pre-generate the qvd files for the users, connect them to the database and pull the data directly to their laptops. This can further restrict their access to the data based on their security levels in the database.
Downside is it will increase each individual users load times. As mentioned previously, SBE is well worth the investment if you can talk the powers that be into it.
I'm no developer but I think you also can try, instead of loading from every laptop, to create two .cmd files:
NET USE Q: \\IP to server\Folder for .qvd PWD /user:DOMAIN\User
NET USE Q: /DELETE
Change each user document script...
Ordinary reload script - make sure to change the path to .qvd files to use e.g. Q:
netuse.cmd 78 bytes
Have you thought about the use of the Binary load functionality? Don't store the data into QVD's but load your original QVW with Section Access. You can place this QVW anywhere on your network (even without NT security) because you can only read this QVW with QlikView and without a valid user/password combination you cannot read the data inside the QVW.
The end users load there personal reports with a binary load so even the script (the business logica) isn't visible for the end users. Simple and safe. Only those end users with a valid login can use the data!
If you secure your QVD's with NT security and the end user stores the data in an unsecured QVW than your security is broken. Everyone with a QlikView license can read those QVW's!
As per my knowledge, Use the Virtual Server as a QlikView Server means:
1. Make all the Application and Qvd available on it.
2. All the Data reloading Activities on it.
3. Give the users a remote access only to the final Application Folder so that they will either access from there or copy the application to their end.