I'm not sure what the advantage would be to creating a QVD if your QVW both creates it and uses it. What you would essentially be doing is loading data into memory, exporting a file, dropping the data from memory, and then reloading back into memory from the exported file. Typically, it only makes sense to use QVDs if your data is changed less frequently than transformations are made, or if multiple documents need to use the same data. If this is not the case, QVD creation is probably a little overkill for you.
Second, regarding Source Documents vs. User Documents: you will only see this distinction if you have the Enterprise version of Publisher. Do you? If so, then you would define your source document folders in QEMC --> System --> Distribution Services. Then define your User Documents folders/mounts in QEMC --> System --> Server Settings. Then, under Source Documents, you can create a distribution task that will distribute into your User Documents (i.e. your QVS folder or mounts). If you want more detail, take a look at the QVS Reference Manual (way too much to write here).
Third, regarding the Publisher account: typically, this should be a local admin and a domain user. It should be a local admin so that it can start services (many GPOs restrict this). It should be a domain user so it can browse the AD and choose users to distribute to. Check your local security policy and make sure that the account has been granted Logon As Service rights. This should have happened automatically during setup, but sometimes restrictive GPOs can get in the way. So check these things first, and if the reloads are still failing we can troubleshoot some more.
Thanks for the information you provided.
I see what you are saying. We proably are going to have very soon serveral qvw files which will use at least partially the same data. That's why I was interested in getting the data first into the qvd files and then into different qvw files. I agree, currently with just one app it's an overkill.
Yes, we plan to get the puplisher enterprise license as well and I read the docu and think I understand but haven't tried it yet. Business user would never see the content in the source folder, they would only see the content in the user folder. Does that mean that the qvw file is stored twice in to different locations?
Very good points you bring up in the third section. My problem was that the source system, a SQL-Server database needed a login for the windows account the Qlikview server runs under. When I added the login in SQL Server and allowed it read right to the database the import worked fine and as you mentioned the service also needs permissions to write or read to the folders, for instance for the production of the qvds.
I was waswondering if you could let the community know how the limit a users access to specific qlikview apps. For instance I want user A to only beeing see and open App 1 and 2 and user B would only see B for instance. Currently whoever has a license can see and open all the apps on the server.
Thanks again for your input.
Yep, the QVW would exist twice--once as the original file in the Source Documents folder, and once as the distributed file in the User Documents folder. I'm glad you were able to resolve your reload problem!
By default, access control is through NTFS permissions. Therefore, quite simply, if you want to User A to see Apps 1 & 2, then give him NTFS Read permissions on those apps (the QVW files). Similarly, give User B Read permissions on App 2. Then make sure users that should not have access have no permissions on those files. Btw, the recommended best practice is to do this using AD groups, rather than specifying individual user accounts in the NTFS permissions.