we are a new client and want to start on the right foot.
mostly, we're a web app team. we develop on our workstations and publish to dev/test.
this will not work to well with the ram requirements of QV.
We contracted a partner for the install and stand-up of QV. Their reccomendations seems to be that we develop on the server via RDP.
what are you guys doing? limiting record sets ? server development ?
Installing Qlikview in a server and connecting it through RDP is a good option since there is no need to have additional RAM on individual machines. We follow the same for our development.
This also eases the issues in opening connectivity to the source systems and also, all the documents can be maintained in the server without any local copy.
Working on stand alone machines by limiting the record sets might not be good option, since you will not be able to test the performance of the document with full data loaded. This suggestion is based on my experience and you will get more such inputs from others 🙂
thanks for the quick response.
do you ever have connection limitation issues?
we are planning to allow some "super users" to develop as well. does your shop do that? currently, we do not allow non-IT people to connect to servers.
thanks again for the response
I guess, the number of RDP connections is based on the number of terminal services licenses available in the windows server and you can run multiple sessions in parallel provided there are enough terminal services license.
In Qlikview end, you can run multiple sessions, provided there is enough server capacity and you have developer license to allow parallel sessions.
I am not sure about 'Super Users' and I guess this is related to the windows account management.
We develop by maintaining files on the server, usually no local copy. There is a development, test, and production environment. However, our test environment should really be called "staging for production", because in practice, we test everything in development, and not in test.
We do open the server files on our own computers, so our own computers must have sufficient RAM. There are a few applications that are too big to open in 32-bit, which is what all our desktops are. For these applications, we have single, shared 64-bit development machine. We just "remote desktop connection" to it as necessary. Since there are only a few applications that need this, we've never had any conflicts that couldn't be resolved by communication and a brief discussion of priorities.
We do not have connection limitation issues. Though I suppose I'm not sure what you mean by connection limitation issues.
We do not have super users doing any development. Like you, we planned to have them, but none of our super users ever did more than poke around at things with very little understanding of what they were doing. They very quickly lost interest, asked IT to do everything, and we abandoned the super user idea. But yes, during that phase, our super users had access to the development server only. We did, though, have different directories on the server, with different people authorized to each. So the super users couldn't, for instance, go in and delete an IT-controlled application.
thanks for responding and good info.
windows server is limited to 2 concurrent connections via rdp unless we make it a terminal service machine. as i understand it, those licenses are expensive so we are to stay away from that idea. to be honest, i'm relying on my server guys on this subject.
we have another remote option via sccm which, in our environment, is hosted on citrix. that is not quite as clean as rdp but we may not have much choice.
I think my question stems from this conversation. Excuse me if not, I'll open a new one if you think I should.
For the last 12 months I was a in a Graduate position working closely with QlikView applications. We use RDP sessions to our Dev/Prod servers as suggested above. Until recently we only ever had 3-4 people working on QlikView (Or had any QlikView knowledge at all).
QlikView is now beginningto be widely used across our businesses and now there are a number of projects in the pipeline and the number of developers working on these servers is approaching 10+.
Simply put, the file structure we ue on Dev/Prod is a mess, we have no documentation detailing any standards or practices to be followed.
To nip this in the bud before it becomes a problem I am working to tidy the files we already have and produce documentation to have guidlines for new developers.
Does a best practice model exist for file structure of QlkView servers?
I don't know about BEST practice, but if we ever cleaned up our actual practice, it would probably look something like this:
There are certainly more directories, but that's the basic idea, and now I'll explain. Each big category of the type of data has its own directory. These directories have separate access control over who can get to the applications within. The Master_Data directory contains most of the QVWs that do nothing but create QVDs, and the results go in the QVD sub directory. Some categories of data, like accounting and particularly payroll data, are sensitive enough that they should be protected from most people in IT as well. So the sensitive QVDs go into those specific directories so that access is more tightly controlled. The QVWs that create those QVDs obviously go in the controlled directories as well.
We don't have any issues with concurrent development because for the most part, each QVW has an owner, specified on a fairly standard format About tab. Some of the QVWs in the Master_Data directory don't have an owner, but they're rarely touched, and we at least often chat about what we're doing even if we don't have an official check out policy for them, so we've never had any problems that I'm remembering. For an environment with 10+ developers, unless you have an owner for each application, you'll probably need something more sophisticated than "hey by the way, I'm adding some fields to this QVD". I'd recommend some sort of code versioning and collaboration software. I have no specific recommendations as far as what software to use. If you don't want to go that far, perhaps you could implement a policy where if you want to develop an application, you copy it from the server and put your name at the end (e.g., Customer_Orders.qvw.JohnWitherspoon). Then when you're done, copy it back and remove the old file. If someone sees your name on a file, they know you have it checked out and know who to talk to.
As far as standard practices, we initially tried to create some standards documentation. This has not been followed. I haven't followed it. I'd rewrite it now to match my own practices, but that wouldn't change anything.
Perhaps a good approach would be to set up a template with examples of everything from your standard color scheme to how date fields look and how line charts should look. We haven't done that, and I don't know if that would be effective in practice.
Something I've recently done that I wish I'd done a lot earlier is set up a Calendar QVD. This lets me stop repeating calendar logic (however simple it is in practice), and makes sure that all applications using the standard Calendar also get the standard formatting for dates, months, quarters and so on. If you can do something like that and get everyone to use it, that might help with enforcing standards.
This is pehaps only peripherally related to the question, but I recommend forbidding developers to EVER load * from any data source but an inline or resident table. If your application doesn't have control over the source, never ever load *. Yes, when your QVD only has 10 fields, and you want those 10 fields, listing them all may seem like a pain. But that is NOTHING compared to the pain you'll suffer when someone adds another field to that QVD that they require, and then your application reads it in, and then it links up your data models in incorrect ways, and breaks your application. And even if it doesn't break your application, the slow accumulation of fields you don't need in your tables will take more and more memory and make your application slower and slower. Multiply that by 10+ developers and 100+ of applications, and hopefully you can see the problem. A little investment up front can save a lot of trouble later.