Hi @Dave_Laycock1 (and anyone else who can help) -
Sorry to disturb you again. I tossed up creating a new thread and decided to continue this one…
I got around to coding the TN document/delivery export process using this code pattern. Have you used this code pattern before in your TN data exports?
INVOKE wm.tn.query:createDocumentQuery
INVOKE wm.tn.query:documentQuery (Returns enumeration identifier to access paged query results)
SET N=1
REPEAT until 'enumerate:nth' call below returns no results
INVOKE wm.tn.enumerate:nth (Read page N)
SET N=N+1
Unfortunately, with large datasets I’m getting inconsistent result sets in consecutive runs. I suspect the wm.tn.enumerate:nth
call may be outpacing the results returned by the server-side query thread. But I am not seeing error messages such as “Requested page is not available” or “Invalid or missing page number” I’d expect if this were the case. TN is silent. So I’m not sure how to handle this: inserting delays makes it worse and the WmTN documentation is of no help. I’ve increased the tn.query.maxrows parameter to tn.query.maxrows=500000
to ensure TN doesn’t truncate results. It’s a situation.
I suspect my code may need this additional logic :
- loop over the current page (LOOP over
wm.tn.enumerate:nth
with pageNum=N), and delay reading the N+1th page until the ‘enumerate:nth’ call signals it is available (N < pagesRead
) - only exit the loop if it is already at the last page (
N = totalPages
)
But it’s hard working with large datasets and TN policy of silence on any errors. So I’m asking in case you or anyone has experience or ideas on using wm.tn.enumerate:nth
PS: I’ve updated the code and still hit the same problem. I’ve posted this now in a new thread: