I'm not using this specific file any more, so I can't confirm it, but I think I know what the problem was on the SQL side. This doesn't excuse QlikView locking up while waiting for data, but just in case it helps someone:
Microsoft SQL uses a technique called "parameter sniffing" to create good execution plans for stored procedures. Basically, the first time you run a sproc the database will build and store an execution plan based on the parameters you gave it. If you later run it with different parameters, the stored plan could be drastically inefficient.
For example, say you have a sproc with @StartDate and @EndDate parameters. You create it, and run it with the date 2011/04/27 for both the start and end date, just to see if it works. SQL looks at that narrow date range and decides that an index seek is appropriate. Later you run it with a start date of 2000/01/01 and an end date of 2011/04/27. SQL still uses its index seek execution plan, even though what it really needs for that broad date range is a table scan. This can make a huge difference, leading to run times of hours rather than seconds - I've seen it happen.
The fix is to specify reasonable parameter values when you first run a sproc after creating or re-creating it. This will help SQL to build a well-optimized query plan at the beginning.
More info: http://www.simple-talk.com/sql/t-sql-programming/parameter-sniffing/
.png "Miguel_Angel_Baeyens"){kind=avatar}
