Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
paulferguson80
Contributor III
Contributor III

Access Denied! The server is currently out of SESSION and USAGE CAL's

Hi All,

Im hoping someone can help...........

We currently run 200 document Cal's and 50 Named User Cal's.

We have 19 documents in our access point.

Since we have come back after the new year I cant access 6 of the 19 documents and get the error message

"Access Denied! The server is currently out of SESSION and USAGE CAL'S"

Using a Named Cal i should have access to all of the documents as i previously did?

I have tried removing the report's meta data as per advice found on the community as well as removed the FUL.dat file and the pgo files for the access point to try and get the server to recognise the cal and allow access to the document.

I have also tried removing and replacing (from backup) as well as renaming the document and the same problem persists?

As a last ditch attempt i have also tried removing the documents and renaming them as well as a server install repair (just to be sure all bases were covered)

These documents will open on the server without any issues, reload fine every day however when using the management console I am unable to set doc cals on it as I get "Failed To Set Document Metadata" ????

If anyone has had a similar problem and can shed any light on how to resolve this issue your assistance would be greatly appreciated

Many Thanks

Paul Ferguson

1 Solution

Accepted Solutions
Not applicable

This worked by the way.

There are two sets of PGO files.  One set is under C:\ProgramData\QlikTech\QlikViewServer (or whereever you installed QV).  This directory is also where you will find the additional DAT file.  The other will be under the mounted directory where you store user documents.  I also found a file whose name had a lot of Japanese characters that I deleted as well.  Don't know if that had anything to do with anything but it seemed wierd as we don't use the Japanese version. 

Finally, once I reentered all of the security information (named and DOC CALs), I saved the PGO files so that if this happens again I can, hopefully, copy over the working versions. Hope this helps!

View solution in original post

22 Replies
Not applicable

I would be very interested to hear the answer on this one as we are having the exact same problem with one of our documents.  Have you had any luck with the resolution?

Not applicable

Our document suddenly started working again even though we did not change anything.  Our vendor suggested that one user perhaps corrupted the file and it wouldn't get "uncorrupt" until they opened it again.  I'm not saying this makes total sense but it does explain why it would suddenly start working.  So, in the future, we are going to either find out who last opened the file and have them open it again or have each user open the file until we find the corruptor.  Make sense?

Just wanted to put this one out there in case anyone else has the error and needs something to try.

Not applicable

We have also just come accross this Issue after applying SR4

We have now logged this as an issue with our QV partner and are waiting to hear back from them. Did you get a resolution to this?

Lawrence

paulferguson80
Contributor III
Contributor III
Author

Hi All,

Im still awaiting a response as to why this has happened and a resolution to the problem from QlikTech.

As soon as I get one or find something that works I will post on this feed

Many Thanks for any suggestions made, unfortunetly we are still expiriencing this issue so if anyone has found a resoluton please share

Many Thanks

Paul

Not applicable

Hi,

I am also looking forward to QTs reply... also had this issue today.

Thanks,

Martin

Not applicable

This happend for us again this week.  The response from QV is that there is a bug in QV10 SR3 to QV10 SR4 and may also be present in v11 and QV9 SR7.  It is bug #44779.  To quote the email "The bugh has not been solved yet, but it has the highest priority and we are most likely looking at a patch when it gets fixed.  The "best" workaround at the moment is to remove the PGO files.  Note that this WILL clear any User Cals set up in the environment, they have to be added again manually. "

So stop the QVS service, backup PGO files found in /QVS folder of QlikView Server and your Documents folder.  Delete the PGO (again keep a backup).  Restart QVS service.  Make sure everything still works and then setup your security again. 

I haven't tried this yet but will give it a go tonight.  I am going to make a backup of the "uncorrupt" files once I am done so that I can recopy them over rather than recreating everything anew if it happens again.  I'll let you know if it works for sure. 

Not applicable

Sorry, also a DAT file found in the /QVS folder.

Not applicable

hi,

can you give me a hint where I find these files? actually there are a lot of pgo files but I am not sure about which to delete. Could you give me a full example path for that?

Thanks,

Martin

Not applicable

This worked by the way.

There are two sets of PGO files.  One set is under C:\ProgramData\QlikTech\QlikViewServer (or whereever you installed QV).  This directory is also where you will find the additional DAT file.  The other will be under the mounted directory where you store user documents.  I also found a file whose name had a lot of Japanese characters that I deleted as well.  Don't know if that had anything to do with anything but it seemed wierd as we don't use the Japanese version. 

Finally, once I reentered all of the security information (named and DOC CALs), I saved the PGO files so that if this happens again I can, hopefully, copy over the working versions. Hope this helps!