Skip to main content
Announcements
Defect acknowledgement with Nprinting Engine May 2022 SR2, please READ HERE
cancel
Showing results for 
Search instead for 
Did you mean: 
stevelord
Specialist
Specialist

Make NPrinting stay to sheet 1 of qvw on open?

NPrinting 16.0.0, Qlikview 11.2 SR12, Windows Server 2008 R2 Enterprise

Hi,  Is there a way to consistently make NPrinting open a qvw to a particular sheet  besides the qvw's own OnOpen trigger that NPrinting seems to be sidestepping?  This is to help NPrinting open to a lightweight sheet and not risk errors related to the document taking a long time to open or load/calculate stuff on another sheet.  More detail below if desired.

Some of my qvws are a bit large and have some tabs that are calculation-intensive to suit certain business needs.  In order to help them open faster, I set OnOpen triggers to activate sheet 1 which just has some list boxes so people can narrow selections as desired before moving on to the calculation-intensive tabs.  This way if a user wants to see only one client's data aggregated, they can move more quickly, and if they really want the book of business aggregated, they have that option too.  NPrinting is one of the 'users' who sometimes needs only one client and sometimes needs the whole book of business aggregated too.

When I run the nprinting job manually, I see the qvw open to the sheet 1, but for some reason NPrinting is jumping out to another sheet in the middle.  It's not the sheet with the desired tables, nor the sheet I last worked on, accessed ,or saved, so I'm not sure how/why NPrinting is deciding to hop over to that sheet.  This seems to be the sequence:


open to desired sheet 1,

clear all,

jump to calculation intensive sheet it doesn't need,

--wait a long time,

--sometimes make selection sometimes error out,

export table from a different sheet,

save/email it,

close qvw


I can avoid the issue by opening the qvw first and waiting for it to load, then running the nprinting job, so guessing that aside from picking the sheet that makes its life harder, nprinting is just trying to move a little too fast for its own good sometimes.  (I have another nprinting job that prints 40 reports, consistently messed up report 1, and I made a little cleanup job to re-do report 1 after the other 39 are clear.  I chalked that bad report 1 up to nprinting impatience, and other clean reports to qvw being loaded by the time nprinting started those. )


Actually, maybe a way to tell NPrinting to pause for an extra 30 seconds after opening a (large) qlikview might help.  But having it stick to my cover sheet tab would be nice too.

5 Replies
Ruggero_Piccoli
Support
Support

Hi,

Triggers on source QlikView documents are not supported and should be removed to avoid errors.

You could save the original .qvw with all charts minimized. This avoid calculation while opening it by Qlik NPrinting. Only the charts maximized during reports generation will be calculated.

Best Regards,

Ruggero

---------------------------------------------

When applicable please mark the appropriate replies as CORRECT. This will help community members and Qlik Employees know which discussions have already been addressed and have a possible known solution. Please mark threads as HELPFUL if the provided solution is helpful to the problem, but does not necessarily solve the indicated problem. You can mark multiple threads as HELPFUL if you feel additional info is useful to others.



Best Regards,
Ruggero
---------------------------------------------
When applicable please mark the appropriate replies as CORRECT. This will help community members and Qlik Employees know which discussions have already been addressed and have a possible known solution. Please mark threads with a LIKE if the provided solution is helpful to the problem, but does not necessarily solve the indicated problem. You can mark multiple threads with LIKEs if you feel additional info is useful to others.
stevelord
Specialist
Specialist
Author

Thanks, I'll call this helpful and will likely end up with an assumed answered on this thread if the specific function I'm looking for isn't present.  I was looking for some checkbox/enter sheet id type solution that would spare me the effort of revamping dashboards further.  I have gone as far as to give NPrinting its own versions that I can tailor to its needs, so no impact to human users if I have to revamp NPs qvws further at least.  I also figured out that dumping all the objects into a container object makes it so only one thing is calculating at any given time, but I only did that for objects designed specifically to cough out raw numbers for nprinting to take.  The various charts and graphs on other tabs are still the way they are for human users' whose dashboards I cloned and modified for nprinting. 

Edit: Also the onopen trigger to go to sheet1 was only added to try to get nprinting and users to the cover sheet and it works okay for everyone including nprinting, just nprinting wants to jump elsewhere after that trigger puts it on the right sheet.  I don't have any other triggers, and use nprinting's functionality to make selections and such.  I can see where the wrong kinds of triggers might make conflicts for nprinting,and possibly any triggers might add a bit to load times which nprinting won't have patience for.  But I think the onopen->activate sheet trigger is the most benign in either regard since it executes in a split second and everything else not so much.  NPrinting doesn't seem to care what sheet it's on and can get tables from wherever as near as I can tell, just having the odd thing where it hops itself to the random other sheet after opening the qvw.  (I wonder if that's the first sheet I created in the document back in history and nprinting sees that in metadata somewhere.)

Random bonus tip: Switching from Now() to Today() for various expressions was also a huge help in reducing calculation efforts.  (Way back in the beginning I had graphs that would calculate, then recalculate endlessly as fast as they finished calculating.  It took me probably too long to understand why that was happening. )

Anonymous
Not applicable

Only thing I can think of is to base your triggers on the user using OSuser( )

Lech_Miszkiewicz
Partner Ambassador/MVP
Partner Ambassador/MVP

My observations were completly different.

NPrinting was opening sheets and was jumping between them in order to pull objects from each individual sheet where object used in report was sitting - They were not random!

I guess it also depends on which sheet you save your document on.

I also find Containers extremly difficult to deal with when used with NPrinting - most of cases, bugs, issues were around Container objects that is why i have never used them.

I would still avoid using triggers / any triggers. On the other note-are you using qvp connection or local connection to file?

cheers

Lech

cheers Lech, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful to the problem.
stevelord
Specialist
Specialist
Author

Maybe I mistook the apparent random jump for it actually picking up one or another table from a tab I hadn't remembered a table being on.  And maybe your experience with the container objects is similar to what I noticed with my 'report 1 of 40' coming out screwy but reports 2 through 40 coming out alright.  Like maybe objects in the container need to be touched by something once before they'd go onto the template correctly. (My report 1 used to show like <Table 1> tags instead of the actual tables, and reports 2 - 40 would show actual tables. Then I made a separate little nprinting task at the end of the job to redo report 1 after the others which made all 40 okay.)

Anyway, thanks all for the optimization ideas!

Edit: I observed more closely while an nprinting job was running and the tab of the qvw it decides to jump to is the very first one that existed for that qvw, and the other tabs are ones that were added later.  While the tab it jumped to has none of the tables or charts it's using, I do see it making selections on the dashboard as it moves through the reports.  I don't think nprinting needs to be on the same sheet in the qvw that it's desired table is on because it might be operating on the qvw's repository of objects.  This is nprinting 16 I have, and I'm thinking of the part where you refresh object list when setting up the connection to the qvw and how you drag object ids from the nprinting's list onto the templates   So now I have a thought about just cloning that tab for end users to use, and making the original a blank/hidden tab for nprinting's benefit.  (The objects nprinting uses are off on other tabs at the end and would be unaffected.)