On the first glance this error indicated that the QlikView Server is unable to reach the share.
In detail the "Time" parameter states the amount of time in Milliseconds the operation(s) took before aborting for the error related to the error code. If this number is high (like in this case) and the error code is either 11 or 12, we can draw the conclusion that QVS made as many retries as it could fit within the fixed timeout of 30 seconds.
Please verify that you are not experiencing network issues during the time when the problem occurs, but be aware that this could have a number of causes. Submit a Support ticket through the right channels if necessary, just make sure you include all necessary details like QVS version details, log files and also let us know what network storage solution you are using (NAS, SAN, whether they are windows based or not, etc).
Sonja Bauernfeind Senior Technical Support Engineer and Knowledge Centered Support Gremlin
To help users find verified answers, please don't forget to mark a correct resolution or answer to your problem or question as correct.
All, this was a bug in earlier versions of 9 and 10, the issue is fixed in SR3 of version 10 that was released today. Not sure if we have a SR out fixing the issue in version 9, please let me know if you need a fix for it in version 9 as well and I will see if I can find a patch for you on Monday.
Unfortunately not, if the upgrade to SR3 doesn't solve the .meta issue as well, please report it to qlikview support at email@example.com<mailto:firstname.lastname@example.org> and attach the qlikview server event log file, this will help the support to find the problem you have.
We installed SR3 last weekend and we are still seeing a variation of this error in the Event log. In our case, it is usually IniData.pgo or CalData.pgo, though occasionally ServerCounters.pgo is also cited. This problem is not fixed in SR3 for us.
We are running QV10 SR3 on two dedicated test servers running Windows 2003 Server on VMWare ESX.
Interestingly, this problem, and several other problems where .qvw.log files can't be written to, and .Meta files are reported as "missing" when they are in fact, present, does not occur when we disable the second QVS service, so that the cluster has only a single QVS service running.