Hmmmm … testing these specific ranges gives you consistent results? NO deviations? If so, I’ve got no idea.

Have you tried to copy the SOQL out of the model to try the same in SF developer console? If the same error happens here then I’m stumped. I’d additionally want to see the SOQL.

Glenn, that is pretty confusing, I agree. It sounds like your Model query is right on the edge of consuming the Apex Heap Size limit, which is 6MB. There’s a lot that contributes to this limit being exceeded, and only some of it is within your control. Also, we are actively working to reduce Skuid’s Apex Heap Size consumption — the next Millau update release, 11.1.9, will include some changes that should reduce heap size usage significantly, so when that comes out (~ 2 weeks from now) I highly recommend getting that release. 

However, in the mean time, there are a few things you can do to reduce heap size consumption:

1. Are you only querying for one Model in this page? Or are there multiple Models? If there are multiple Models, it’s worth considering whether you can load some of them asynchronously. If however you’ve only got one Model on the page, then let’s dissect what all’s going on in that Model.
2. How many fields are you requesting on your Opportunity Line Items Model? Do you need all of these fields? Each field you remove will contribute significantly to reducing heap size usage, because with each field you request, Skuid has to request field metadata as well as query for that field on every row, so reducing the fields you query for is the most effective way to reduce heap size consumption.
3. Do you need to load 1500 records into the table on page load? Could you just load, say, 200, and then allow users to request more using “Load More” on the table?

Hopefully some of these get you started.

The query I am trying to run is below. When I run it in dev console it returns records.

SELECT Opportunity.RecordType.DeveloperName, Opportunity.Probability, Product2Id,Product2.Name, OpportunityId,Opportunity.Name,TotalPrice,Opportunity.RecordType.Name, Opportunity.AccountId, Opportunity.Account.Name, 
Name, Opportunity.RecordTypeId, Opportunity.CreatedDate, Opportunity.CloseDate 
FROM OpportunityLineItem WHERE ((Opportunity.IsWon = TRUE AND Opportunity.CloseDate >= 2017-08-01) OR Opportunity.IsWon = FALSE) AND Opportunity.Probability >= 20 AND Opportunity.Probability <= 60 AND Opportunity.RecordType.Name != ‘Grant’

I have 7 aggregate models, and 1 basic model.

The basic model pulls through the following fields, all of which are required.

Opportunity.RecordType.DeveloperName,

Opportunity.Probability,

Product2Id,Product2.Name,

OpportunityId,

Opportunity.Name,

TotalPrice,

Opportunity.RecordType.Name,

Opportunity.AccountId,

Opportunity.Account.Name,

Name,

Opportunity.RecordTypeId,

Opportunity.CreatedDate,

Opportunity.CloseDate

All of the models need to be called at once. Below is a screenshot of the page.

I’ve restricted the number of records loaded for the table that appears when “Show all” is clicked to 200 and it seems to work without error. So I guess it’s working fine now, but seems like a small number of records to cause such a problem.

You apparently edited out a sentence about the user clicking Load More. I wonder if you discovered the Export options for the table and if those settings have any bearing on the issue.

this is exactly what I’ve found, and I think it resolves the issue for me. Though I’m still curious why I was hitting limits, it doesn’t make immediate sense?

That is strange for sure. The agg models shouldn’t be part of this issue.

This leaves some weird issue that only Skuid can resolve since the query runs without issue in developer console.

How many records are being returned in the Aggregate models?

Oh yeah… Group by

I think the aggregate models are pulling through 9 records (see screenshot to make sure i understand you correctly). I don’t know if it’s worth mentioning, but the basic model orders by two seperate fields, could this be causing problems?

Hmmm … agg models isn’t an issue then. At least I don’t think so. Heap size is based on the size of the records package. # of fields per record affects this greatly.

The Order By w/ 2 fields also shouldn’t be an issue.

Honestly stumped since a query that should return less records is an issue and the a query that should more records isn’t an issue.

If the heap size is affected by the content of the records as much as by the number of records, then the fewer records may be larger (wider?) than the records with the greater quantity. Does the data size of your fields vary significantly?

This can’t be the case here since the query returning more records would include all the records from the query returning fewer.