Qlikview Questions before implementation

[#1]

Hello Guys,

This is my first post as we progress towards Qlikview as our analysis tool.

Please direct me to the thread if you think these questions are already answered. Also, I am looking towards users perspective than a sales persons.

Can anyone answer these questions from their own experiences of implementing or using Qlikview?

1) Can we use Virtual Machine to implement Qlikview Server/Desktop?

2) If we are working with mutliple geographies, what is best place to have the server. (Is it each geography having its own server or one server at corp HQ to address all analysis needs)?

3) Is the Qlikview desktop license or features different between general users, power users and administrators?

4) When doing daily incremental loads, do we rebuild the .qvd's daily or is it just merging the changes?

5) What is the backup mechanism for QVD's? (I mean what if the QVD gets corrupted?)

6) What is the security model like?

7) What about backups of metadata? is it stored in some file or in an external database?

😎 What was the turn around time for you guys when implementing Qlikview. from requirements to complete implemention?

😎 How was the training model provided by Qlikview like?

[johnw · Accepted solution]

1) I'm not sure exactly what you mean by "Virtual Machine". However, I do know that we're running multiple virtual QlikView servers on the same physical server. I'm guessing that's what you mean. If so, yes, you can do it. I'm not aware of any problems or difficulties, though I'm not directly involved in that part.

2) Not sure. We only have one physical location.

3) I'm unclear what the current licensing scheme is, and it keeps changing. When we started on QlikView, I believe there were three feature levels, which you could describe as general users (use the reports), power users (can modify reports but not any of the underlying data structures), and administrators (can modify reports and underlying data structures). I THINK that general users and power users have been rolled into the same feature bucket now, and that we're controlling who is allowed to do what outside of Qlikview.

4) A normal incremental reload might look like this - load new/changed data from database, merge with all data from QVD where wasn't loaded from the database, store resulting QVD. If you can also delete rows from your database, there would be an additional inner join with all of the IDs that are still in the database, which would have the effect of removing the deleted IDs from the QVD. The full QVD file IS read and IS updated, but it's also just merging the changes, so I'm not sure how to answer one way or the other.

5) I don't think we're backing up our QVDs because we ARE backing up all of the source data for them. So even if the QVD gets corrupted, we would just delete it and rerun the load. Even our incremental loads have been coded to recognize that they need to reload everything if the QVD is missing.

6) I'm not in charge of our security, so take this with a grain of salt. Also we're still on 8.5, though it looks like 9.0 will behave similarly. In publisher, we list the users that are allowed to access each file. It creates a separate copy specific to each authorized user, and only that user can access that copy. These copies can also go through "data reduction", removing information that specific users should not have access to.

7) I'm not sure I understand the question. All of the QlikView script and charts and so on are stored in a QVW file. Back these up the way you would any other file.

😎 When we FIRST implemented QlikView, it probably took a month before we had applications up and running, but I wasn't involved that early. These days, it all depends on the complexity of the application, and whether or not we've already "staged" the information in QVDs. I can have simple applications using existing QVDs up and running in a day or two - talk to the user about what they want, write a quick script and some basic charts, and give it to them. Then go through a few very fast iterations of "can you add this field?" "can you put in a chart like this?". More complicated applications take more time. My most complicated application probably took me several months to half a year to develop. However, that was years ago, and I'm much better at QlikView now. I could probably do something similar in a month today. So at least in our shop, call it several days to a month to develop a complete implementation, at least once everyone knows what they're doing.

9) Training? Eh, someone showed up and gave us a few days of training. It was enough to get us up and running. The rest was pretty much self taught and shared knowledge. There's more training available, but we haven't availed ourselves of it. We haven't needed it. I'd say that between the help text, the API guide, and the helpful people on the forum, we can solve almost any problem.

[rwunderlich]

I'll answer those questions where I have some experience.

1) Using VM is possible. In my experience, it works fine for Desktop. I've tested some with Server & Publisher and have not been happy with the performance for Production. This may be mostly due to my lack of experience in tuning VM.

3) In 8.5, there were three license levels a) Analyzer -- the read-only end user, b) Professional -- the Power User/Developer c) Enterprise -- Script developer with all features of Professional as well.

In V9, there is only a single developer type license. Any user can become a developer by assigning them to a "Named User" license on the server.

Administrator functions, which are Server and Publisher controls, are done via webapps which are secured by Windows userid. Use of admin screens does not require a user license.

4) I just merge the changes.

5) The backup mechanism is the same you are using to backup your server file systems now. A recovery would be restoring the QVD to the good backup and rerunning the incremental loads. I try to design my incremental loads to load everything since the latest transaction in the existing QVD -- as opposed to "load yesterday".

6) The security model provides for controlling who can open a document and what rows of data they can see in the document. Security specifications can be loaded into the document (Section Access) or assigned by QV Publisher. I prefer the latter. Credentials may be Active Directory, something called DMS which can plug into other security directories, or coded in the document.

Feel free to ask more about the security if you have specific questions or want to clarify a point (anyone know if there's a good whitepaper on the subject?)

7) Not sure what type of metadata you are asking about. Document (application) metadata is stored in the qvw file along with the data. So the backup is a backup of the application. There is no central repository of metadata about the documents although many of us have created them. For example, catalogs of available QVDs. There are interfaces -- QV functions and VBS APIs -- to extract metadata from documents.

The server metadata is stored in files on the server (and perhaps the registry). Backup is filesystem backups of the server config data.

The Publisher component keeps information about it's tasks -- reload, distribution, user rights assignment, etc -- in a repository called QVPR. QVPR can be either XML stored in the server filesystem or a SqlServer database. The administrator decides which and freely migrate back and forth.

😎 Implementation time was relatively fast. We had the server environment established and our first few apps in production in about three weeks. For the initial POC, I developed three sample apps in a week. QV is very fast to develop in, but the actual implementation of any given document is more related to data than working in the QV piece. For me it's about 85% of the time analyzing and acquiring the data and dealing with quality issues, and only 15% coding screen objects (charts etc).

Some tips for implementation:
1. We assigned a "data quality" score to each of the various data areas we were planning to report on. We then went after the high quality first to get some quick wins and experience.

2. Have a plan, and possibly a review team, to architect and monitor your QVD creation. The QVDs become the data warehouse for QV. Because it's so easy to create new applications and QVDs, you can run into problems like redundancy or mismatched time frames if the process is not monitored. There is no central repository to enforce the "big data model".

9) I did my initial training by using the PDF tutorial. We trained the first group of developers by bringing in a trainer from QT for several days. We have done that a couple more times for subsequent groups and it has been very beneficial. There is some online training available on the website, but we have not made much use of that.

We brought in a trainer from QT to teach the first two groups of Analyzer users. Since then we have presented that training using our own people.

Good luck!

-Rob

[#4]

Hi,

Does anyone know if there is a good way to lock down QVD files. My concern is data security. I would like to use them but it appears that other than locking down the folder they exist in, anyone can copy the file and place it in a non-secure location (or worse yet, just take it). In order to use it I would at minimum have to give read permissions.

I'm curious how others have implemented use of them. It would be nice if they could be encrypted and locked down.

Thanks in advance,

Arturo

[johnw]

Our QVDs go in their own folders, and are locked down with folder security. Most of them are in a single, central QVD folder to which all developers have access. But some need additional security. Since I don't work on payroll systems, for instance, I should not be allowed access to the payroll QVDs or QVWs. So those are in their own set of folders to which I am not given access.