Long Integer: Looping and Line Count

As is mentioned in the Meet Long Integer post, the the Count aggregate property is now a Long Integer, but the Table Records Start Index and Line Count and the For Each Start Index and Maximum Iterations all want an Integer.

That makes for some clunky work-arounds if you want to iterate from 2^34 to 2^34+100. 

The Meet Long Integer post ends with "All warnings and errors will be detected at development time. They can be solved with simple variable and attribute data type changes as described in  validation messages."

Following this advice if your Aggregate returned 2^31 records, and you have For Each Maximum Iterations  set to LongIntegerToInteger(GetRecords.Count()) all is well, but once you have more than 2^32 records you will loop 0 times because 't' is outside the boundaries of the Integer values and the function will return the Integer default value (0).

There have to be better patterns for handling these problems that wouldn't exist if everywhere else that takes an Index or a Count would also use Long Integer.


even though I agree that it should be handled correctly. I am wondering what use case there is to actually have paginating for that many records.

Imho the lists should be small to keep a bit of performance?


I thought the size might be used as a reason. I agree that iterating over a large set of records, even from 0 - 2^32, is bad for performance. That's why I used an example of just 100 records from 17179869184 to 17179869284.

If it only makes sense to query less than four billion rows (and not use an aggregate since they don't support offset), what is the use case for returning the count as a long integer that then needs to be cast everywhere you'd use a count?

I picked the loop example and stretched it's size out to emphasize my concern about the hidden errors or special handling that might be needed every time you might be casting from long integer to integer, but maybe I've been implementing a wrong pattern. 

I'm going to go review my use of Count since the Meet Long Integer post said warnings and errors due to the change should be rare occasions and my list of warnings doesn't make it feel rare. I've started out by reading up on the more in-depth posts about Top in Advanced Queries and Query.List.Empty vs Query.Count.