Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
the new report I have built is supposed to be run locally by the users whereby of course they use the qvd file.
It seems to me that the qvd file is being blocked as long as an app supposed to read it is open - even if it's not being read, can that be?
Anyway, our primary load_script runs once an hour and at that precise time, if the qvd file is blocked and cannot be written to, of course there is an error and the whole thing fails.
Is there any way I can prevent that?
Thanks a lot!
Best regards,
DataNibbler
Hi Marcus,
well, I do have access to the directory on tthe server where the log_files are stored. That was one concession by the IT_guys.
Do you think that it would be possible to build a solution from there? I tried once with that INUSE_file - but I cannot load the properties of that file (filetime or filesize), that's why I went for the filetime() of the qvd last time - but I cannot really go that way because that data_loading_script runs for quite a while and I cannot well ask the users to keep QlikView closed all the time, else the report will become a lot less practical for them ...
Best regards,
DataNibbler
Hi DataNibbler,
such file-blocking should be really an rather seldom exception. If it happens quite regulary then there are any conflicting processes and if they aren't obvious (like parallel running tasks) then you will need the logs from the qv-server, the OS and other processes like an anti-virus/firewall to find the conflicting process directly or at least a suspicious pattern.
- Marcus
Okay,
I don't have access to the logs from the server, so I could only check parallel-running QlikView apps - and we have taken good care to make sure they do not conflict (all the apps running by a schedule on the server) - so I guess that is the point where I decide that it's not worthwhile to analyze this further - since, as you suggest, it is rather seldom - well, it happens about once or twice a day - but the loading_script runs every hour and the odds are that the next run will be fine again. The damage done is not great.
Thanks for your help! I guess this it is with this issue. There are things closer to being worthwhile ...
Best regards,
DataNibbler