While using nprinting, named QV license not always recognized

[stevelord]

Hi community, We have an interesting issue while using nprinting where sometimes when it goes to open the qlikview it gives that error prompt about 'since you are using a personal edition of qlikview...somethingsomething...recover this document.  <Proceed> <Abort>'

I push abort thinking I just need to go pull my named license down again with the open in server feature, but then nprinting pops open the qlikview document and exports the tables despite the error message about me not being the creator of the document.

1> This happens some days, and some days it does not happen.

2> Another user and I are working with this same NPrinting file and related qlikviews, under our own sessions in a remote desktop environment, but not at the same time.

3> We are using a powershell to open nprinting, select the nsq, and select the job and the job opens the qlikview

(The powershell is a big one designed to move lots of files from various places to where the qlikviews need them, then tells nprinting to run the qlikviews.)

Any ideas on why the error message about us using a personal edition sometimes appears when using the nprinting job, and how it can open the qlikview document and proceed without issue when all we do is hit abort?  We'd like to solve this, because having to hit abort is not something we can write into the powershell I don't think, so it disrupts automation efforts.

[stevelord]

Hi Colin, on the qv management console system->licenses->general the checkbox for allow license lease is checked.  Please let me know if there is something like this for me to view in the desktop application; it wasn't apparent to me.

my own user id is on the list of people with named licenses, as is the nprinting service account, but I am logged in as myself when I encounter this issue.

Both the qv management console, and the qv desktop edition in this server environment have lef data present on their respective license tabs.   But the personal edition's lef data is outdated.  QV management console server shows 21 named cals allocated and in use, but personal edition has 5 named cals showing in its lef screen.

[stevelord]

sorry, completely missed this post.  I'm checking these other things now.

[Colin-Albert]

From the QlikView desktop, you can use "Open in Server" to update the licence lease and remove the personal edition restrictions.

[stevedark]

The issue you are seeing can sometimes manifest itself with a leased licence if you double click on a .qvw file to open it, rather than opening QlikView first and then opening the .qvw file.  NPrinting is just falling foul of this little QV glitch.

The recommendation is, as bill.markham‌ has mentioned above, to buy a Desktop licence to use with NPrinting.  This is the only foolproof way of ensuring that you don't get drop outs of this kind.

If that is not practical I have seen this worked around by running a batch file from Windows Task scheduler to open QlikView from the command line with a reload and exit switch, with a small app with very little load script.

The batch file would need something like:

@echo off

"c:\Program Files\QlikView\qv.exe" /r "c:\qlikviewdocuments\reloadme.qvw"

As also mentioned above, by colin_albert , you will need to ensure that the batch file runs in the same user context as NPrinting, and that is of course a user that has a Named CAL.  Watch out also for the fact you can only lease a licence to two machines.

Good luck!

Steve

[stevelord]

Hey Colin, when I login as myself and run the powershell, the powershell opens nprinting, runs the osusercheck job, the job reloads the qlikview for one task then exports the report for the other task.  The osuser I see in the qlikview after the reload, and in the report, is myself.  I had put osuser() as osuser in the script to make a field, then dropped that field on a little table for this test.

PS> Today would be one of the days where I'm not getting the prompt from qv that I have to hit abort to get around the prompt...  on qvs statistics I only see three of the named users logged in presently.  I have a mind to run look at qvs statistics if/when I bump into that prompt again and see if it's 6 people or something.

[stevelord]

Thanks for your help Colin, but I've tried that on days I was getting the error and it wasn't enough to clear the error.  And the error itself was sort of fake because when I hit the abort button, nprinting would still proceed to open the qlikview and run it without issues.  Bill and Steve above and below seem to have worked out solutions to get around it, though still no clue why the issue would happen only on one out of five days.  (OSusercheck was good to help me confirm who qlikview thought was accessing it.  It will likely be nprintserv once we have that account's task scheduler running things.)

Steve's idea about the double-click file name sometimes being an issue might be something and the batch file might solve that (or whatever the actual issue is - seems to me that would happen all the time or none of the time but not some of the time).

Bill's idea about getting a local user license onto the qlikview seems like it would work by sweeping away the issue of lef discrepancies.  Since the number of named cals in use can exceed 5 some of the time and not all of the time, that discrepancy between the qvmc and qv desktop edition lef files might fit the pattern.

I'd like to get the lef data in the qv desktop edition updated first just because it is fundamentally wrong and outdated.  Then try steve and bill's ideas if fixing the old lef data doesn't solve it.

[stevelord]

Thanks Steve Bill and Colin for all the ideas and things to check and test.  If updating the lef data in the qv desktop edition, to match the lef data in the qvmc, doesn't solve it likely the batch file or local user license approach will.  I'll come back with correct answer credit for whatever does the job.  (Our network administrator is looking at why qv desktop couldn't contact the license enabler server now.)  Thanks again!

edit, support info from the qv desktop edition for reference:

Client Build Number	11.20.12904.0409
Server Build Number
QlikTech Product	QlikView 64-bit Edition (x64)
License Key	[Leased license]
PE Recoveries Remaining	4
CPU Target	x64

I will look at that license key row the next time the error prompts start, but glad to see it's not eating up recoveries.

[Colin-Albert]

Hi Steve,

Have you checked that the Default Licence Lease Server is set correctly in the User Preferences, Locations on the QV Desktop used by NPrinting?

[stevelord]

Thanks Colin, that value was blank and might've fallen off during some or other updates/network changes we had in the past couple of years.  My network admin told me exactly what to put there (based on what he saw in the post you linked) and the help->update license part still couldn't reach it.  He'll tackle it on Wednesday and I'm hopeful fixing the license info in the qv desktop application on the server will clear up the sporadic snag nprinting is encountering.