Qlik Community

Ask a Question

QlikView Administration

Discussion Board for collaboration on QlikView Management.

Announcements
Join us at the Cloud Data and Analytics Tour! REGISTER TODAY
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

22 Replies
hugo_andrade
Partner
Partner

I also had this problem. I developed a temporary solution.If you open the document "without data" (the only way I could open the document), reload it manually (from QlikView Desktop). Go to the Users Documents folder (access point folder) and move the applications's .META and .SHARE files to another folder (Your desktop for example, but don't delete them). Copy the QVW you manually reloaded from the SourceDocuments to the UserDocuments replacing the old one. Bring the META and SHARE files back.That's it! The next time you reload it (via publisher), all the users will access it normally.Please let me know if it worked for you.

Not applicable

Thanks a lot, it worked.

paulferguson80
Contributor III
Contributor III
Author

Hi All,

Thanks for the responses, I have marked the 2 that worked as helpful as it wont allow me to mark 2 as correct.

I have found a 3rd way to work round this issue so hope this is useful:

We use a windows batch reload process and all of the reloads were working fine and all documents were openable on the server. The problem came with several documents (approx 9) that had this issue.

In the Management Console we were also getting "Failed To Set Document Metadata".

I removed the document metadata and changed the document allocation to "Allow Dynamic CAL assignment" which then automatically recreated the metadata for the report and has "Unlocked" all of the documents that were being problematic and all users with User CAL licencing can access all documents as they were able to previously.

However if I deselect this option the problem re-occurs.

In my scenario this is not a problem as all users of the report that we are allowing dynamic cal allocation are User CAL users so (and restricted through windows permissions) so it wont use any of our free licences.

And now we can wait for QlikTech to resolve this issue.

I can now fully access and manage again all of the documents again as I was able to previously.

PS, if anyone knows how to mark 2 answers as correct let me know and I will change the ones above to correct

Many Thanks

Paul Ferguson

Not applicable

Have Qliktech come up with a resolution for this?  We have just upgraded from v10 SR2 to v10 SR4 and experiencing this issue.  I do not really want to go down the route of assigning User and Doc CALs again.

Bill_Britt
Support
Support

You might want to contact Support. I beleive this is a bug.

Bill - Designated Support Engineer at Qlik
To help users find verified answers, please don't forget to use the "Accept as Solution" button on any posts that helped you resolve your problem or question.
Not applicable

This had no effect for me (QV11 SR1).  I shut down the service, deleted both sets of PGOs, deleted the .dat, started the service... no change.  I'm also getting the "cannot save metadata" error, so they may be related.

Not applicable

That helped, thank you!  Unfortunately in my case it's reserving a license for me even though I am a named user, so this is only a temporary workaround, but it's still helpful.

Not applicable

Hi, Paul and All

The same problem happened to me, even now identifying access problem that was related worksheets. Csv or. Xls.

This time was different, just needed to uncheck the Allow Dynamic CAL assignment and Apply.

So the user could access the document.

After access returned the box to Allow Dynamic CAL assignment and apply.

Access was solved for the user but the bug QlikView continues.

Did not have to remove the metadata of the document.

kind regards,

Luiz Fernando

vindhya_giri
Creator II
Creator II

Hi Bill,

Untitled.png

Can you please explain me a little bit about this error?

We have around 140 Named CALS.

Users were not able to access the documentson AccessPoint. After stopping and restarting the QV services, users were able to open documents in AccessPoint and everything is fine.

Wanted to know what could be the reason for this error ? And, if it happens again, what should be my next steps?

We are using QV11.20 SR10

Thanks

Regards

Vindhya

michael_anthony
Creator II
Creator II

We had the same issue today.  A number of documents refused to open with the message no SESSION or USAGE CALs available.  Our CALs are all named user.  Restarting services seems to have resolved - at least for now.  We haven't made any changes or understand any reason why it would suddenly start doing this.

We are on Q11.20 SR9.  Interesting that the last poster had same issue quite recently.