I'm running into this as well, and it's NOT intermittent. For the current project, it's a show-stopper. I've changed the permissions on the document folder to be read/write by everyone and tried setting the QlikView 7.0 Application identity to the Admin user as suggested in another thread, but nothing I can do seems to be able to successfully run a single EDX task w/o getting this "Failed to check out document with path" error... Running QV 11.20 SR11. The QV event log seems to show little of any consequence (set to high verbosity), I'm not sure if there's any other log I should be looking at:
|2015-06-19 13:45:35||2015-06-19 16:35:30||4||700||Information||Mount: Found Mount at location C:\TPSData\Dashboard browsable|
That's the entirety of the QV event log entries related to the reload attempt. The folder is the correct folder and is the same as that which shows in the error in the Windows event log:
The task "c:\tpsdata\dashboard\idashboardhelp.qvw" failed. Exception: || QDSMain.Exceptions.TaskFailedException: Task execution failed with errors to follow. ---> QDSMain.Exceptions.ReloadFailedException: Reload failed ---> QDSMain.Exceptions.FailedDocumentCheckoutException: Failed to check out document with path: C:\TPSData\Dashboard\idashboardhelp.qvw || at QDSMain.ReloadTask.Reload(String fileName, TaskResult taskResult, String sectionAccessUserName, String sectionAccessPassword, eReloadOptions reloadOption, String variableName, String variableValue, Boolean moniterCpuUsage) || --- End of inner exception stack trace --- || at QDSMain.ReloadTask.Reload(String fileName, TaskResult taskResult, String sectionAccessUserName, String sectionAccessPassword, eReloadOptions reloadOption, String variableName, String variableValue, Boolean moniterCpuUsage) || at QDSMain.DistributeTask.Execute(TaskResult currentTaskResult) || --- End of inner exception stack trace --- || at QDSMain.DistributeTask.Execute(TaskResult currentTaskResult) || at QDSMain.Task.AbstractTask.TaskExecution(ILogBucket logBucket, TaskResult taskResult)
The same failure occurs whether running from the QMC UI or from code using Client.TriggerEDXTask(...)
The same documents I've tried usually load fine when loaded using the OCX (though it has it's own set of intermittent problems that we've had to work around). But we're trying to move away from the OCX given how totally flaky it can be on some customer sites. System I'm testing on is a W8.1 Enterprise, 64-bit VM set to both 4 and 8 CPU cores.
For me, I don't think the available engines is relevant, I'm only trying to fire ONE reload, the system is otherwise completely idle. And as I said, it's not intermittent, it always throws this error, and never gets as far as writing the document logfile.
Hi Keith - do you have any Section Access on the document? Are you able to reload other documents?
The message does imply it is a permission error, i.e. it doesn't even open the document so no logs occur. I'm currently thinking that it is the AD not authenticating the user quick enough so that the Section Access in my app then fails. Not been able to prove that though...
Hmm-- I wasn't sure-- just checked and we are. This could be the critical tip. I'll look into that further and see what I can figure out. Thanks!
How did you resolve the issue ? I have a similar problem. Can you please mention the steps.
hope this is the issue because of using different operating system modes 32/64 insisted of using the same with local desktop and server.
try to use the same in both the cases and see?
In my case both the system are on same operating system x64 bit. I have Qv Server and Publisher on two different machine It seems the server is not able to open the application because of the section access even though I have added the service user name under section access list.
I hope anyone has the solution for this.
I don't think this issue is with permission to execute. When you are able to execute the same app manually, then it should work. But if Section Access is implemented, then you should include the service account on which QV services are running into your users list.
can u try to use Force 32 bit in local and try to deploy the same app on server and see?
hope/i'm sure....it's not problem with section access & service account.
it's problem with application data load on desktop vs server!