In fact, a dev should never use the startLine attribute as it contribute to a loss of performance:
exemple with a SQL translation of the 1rst example:
select top 100 from nmsRecipient
You'll get the 1rst 100 records... No issue about that
Now is the SQL translation of the 2nd querydef:
select top 200 from nmsRecipient
=> as the startLine begin at 100, the "top" will start at 100 and add the line count attributes (100) ... Then the JS engine will keep the last 100 records
This doc is used by developper to create code in order to loop over all the records of a table as queryDef are limited to 10000 records usually:
Imagine a loop with a lineCount of 10K... If you want to use a queryDef in order to operate on a 100K table: it will creates 10 sql queries, retrieving each time 10k more results leading to retrieve 550K results instead of 100K and each requests to be more greedy on performance (10+20+30+40+50+60+70+80+90+100).
The good practice should be then to use an Id (directly the id of the schema or a rowId from a wkf work table if possible) in the where clause in order to replace this "startLine" attribute:
<queryDef schema="nms:recipient" operation="select" lineCount="100"> <where> <condition expr="[@id] > " var.lastProcessedId /> </where> </queryDef> I observed in the past some workflow JS activity with the "startLine" implementation that were optimized from 4h down to 2 min.
Placing a warning in the documentation in order to inform that they should never use startIndex as a way to loop over a schema would be really helpfull, specially for beginners.