If you open a QVW on your machine, regardless of where it is stored, it's in memory on your machine. If you reload from your machine, it's doing all of the work and storing all of the data in RAM on your machine. So for development, you are going to be limited by the capabilities of the machine you are doing your development on. Storing the QVW on the server, while perhaps a good idea from a centralization and backup perspective, will not resolve this problem.
So you're both right. I would suggest storing the QVW on the QlikView server. A developer can then connect to the server, using the client installed on the developer machine, and modify the QVW. However, this will NOT solve client side memory issues. As you believe, during development, the document is on the developer's machine and is using local resources (RAM, CPU). The developer should absolutely carefuly craft the SQL to only bring in the necessary data. Select * from bigtable is a big no-no. It's a massive drain on your DBMS. It's a waste of memory, regardless of where it's taking place. NEVER select * from bigtable. Once the QVW is ready, if it was developed locally it should be moved to the server. Then it is the server copy, using server resources, that would be scheduled to run periodically.
How do we develop with large data sources given these restrictions? We've dealt with it in two ways, sometimes used in combination.
First, most of us have 32-bit development machines with only 2 GB of RAM. But we do have ONE 64-bit development machine with I believe 4 GB of RAM. So for larger documents, we remote desktop into that one machine, and do our development that way. We only have a few documents that require this, and most of them are mine, so we've had very few conflicts. When we have two people wanting to use the machine at the same time, we just communicate verbally and decide who's task is higher priority.
Second, we can limit the amount of data used during development. There are many ways to do this, some already mentioned. As another example, for one application, I've created a trivial QVD in production and test that gives me a starting date for the data I load. In production, it refreshes automatically from a database source. In development, the QVD currently stores the beginning of this year and is not refreshed automatically. So when testing, I'm only loading this year's data, which speeds up the load and prevents memory problems. When I install, it will automatically pick up the full intended data set without any modification of the script.
While not directly related to your question, consider as a general rule NOT doing any ODBC or OLE DB connections in the user applications. Consider instead making specialized applications that do the connection to a single or related tables, read in the data in a generic way, and then store the data in QVD files on the server. QVD files can be read VERY quickly by QVWs, so serve as a way of only hitting your database once, and then letting multiple user applications use the data without needing to hit the database again. These QVDs, at least if carefully designed, will slowly grow into a data warehouse for your user applications. Create them only as needed, but keep in mind the big picture when you create them. Have some idea where you're going and how all the pieces will connect.
