Hi, has anyone else noticed a cap in the number of pages you can get from the query.runSuiteQLPaged method? We seem to get a cap on 1000 pages (notice I’m not talking about the nr of results per page, but the number of pages the method returns). Example: If we run a query with the pageSize set to 5, we get 5000 results. If we set it to 6, we get 6000 results etc. Tried this in more than one environment and get the same problem. Has anyone else notice this? Can’t find anything about it in the docs (might have missed it?)

One of the documented limitations of the SuiteQL REST API is: "Using SuiteQL queries, you can return a maximum of 100,000 results" https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_157909186990.html I'm guessing the 1000 pages is related to that. You need to use another pagination technique, e.g. ROWNUM based https://timdietrich.me/blog/netsuite-suiteql-query-pagination/ Another alternative is using ID based pagination (continue from the last ID that was returned in the previous result)

@Shai Coleman it says: “Using SuiteQL queries, you can return a maximum of 100,000 results *if the SuiteAnalytics Connect feature is disabled. If the feature is enabled, the number of results is unlimited.*” And in this environment the feature is enabled, and even if it was not the issue is not the number of results returned (it’s around 20k items in this case) but the number of pages. As I wrote above, the bigger number I put into the pageSize parameter the more results I get. I can’t use Tims ROWNUM technique because it doesn’t use paged results so there’s a limit on 5k results, and I have much more than that: “Keep in mind that when using this technique, you will still be limited to retrieving 3,000 rows at a time when making calls via SuiteTalk REST, and 5,000 rows when using the N/query module. You’ll have to take that into account when using this technique.” When it comes to using IDs, can they be trusted? I know historically IDs in NetSuite are not 100% incremental and therefor a higher number is not always a newer record so you can sort on it properly..

Using IDs is the most reliable and performant way to paginate in my experience

Yes, IDs will not be strictly in numerical order of record creation, but if you are only processing an existing set of data, it should not be a problem as you’ll still get all records, just not in creation order. I would not use last internal id as a cutoff for incremental updates, as that will lead to problems missing some records, but for processing a full set of existing data it shouldn’t be an issue.