Some more on this: I deleted each condition one by one to see if that would help. It did not. I deleted each agg field one by one. That didn’t help. I deleted each grouping one by one. That didn’t help. I removed the Having statement I injected into XML. That didn’t help. I have a condition based on a date field. I had that condition set to filterable default off. I changed it to filterable default on and set it to show records from last month. This fixed the issue. No errors. I want to see records from at least a year back so I set it to show records from the last 2 Years. Then I got a 404 error in the console on page load. So I set it to 1 year and the page worked again with no error. Out of curiosity, I set the condition to the last 365 days. That worked. Then I set it to the last 600 days. That gave me a 404 error. So it seems in this agg model that is set to have no max records, if I try to query beyond 1 year back on page load. I get one of two errors. If I confine the query to within one year, the page works. If I set the page to not load data on page load, but then query it after page load, the page works regardless of how far back I query. Long story, short, Records from 1 year back is sufficient for my needs upon page load, so this is not an urgent issue for me. Would be nice to know what is up. It is a relatively new object. There aren’t more than a few thousand records.

Hi Raymond. By any chance did you try setting the condition to 366 days? That would be an easy way to see if your error involves records being more than 1 year old. I’m also curious to find out just how many event records are in the scope of the data query. I know you haven’t mentioned any Apex heap-size errors, but the fact that the data loads without trouble when you pull it after page load is interesting. 

I just did some trial and error and found that Last 597 days works and Last 598 days does not work. I’m not getting the User Context error now. I get the following: On Screen Error: null argument for JSONGenerator.writeString() An unexpected error has occurred. Your solution provider has been notified. (System) Console Error: Failed to load resource: the server responded with a status of 404 (Not Found) Again, if i set the model to not load data on page load, then query following page load with the condition completely turned off, it successfully queries all 1446 records without error. Weird…

Which version of Skuid are you working in? I’ve done a bit of looking and judging by the null argument error you mentioned, this may be related to a bug that was found last Spring, and addressed in Rockaway Point Release - Iteration 4 (see “SKUID-2233” in release notes). You might consider testing for this in a sandbox with a newer version of Skuid, or if it’s not critical, keeping it in mind to test down the road when you’re looking into updating your Skuid version. 

As a reminder, Salesforce does not allow reverting back to prior versions of managed packages. Skuid always recommends installing new versions in a non-business critical sandbox environment to test all mission critical functionality before installing into a production environment. We also recommend that you update out of date themes when you upgrade. 

It is happening in 8.8. Thanks

What’s the SOQL generated from the model w/ and w/out load on page load?

Pretend that I don’t know how to find that info.

Thanks for the tutorial… I love new tricks… Unfortunately, the queries are exactly identical with or without load data on page load.

Your welcome. Strange. It’s gotta be a bug.

I got it. It is a bug in the page builder and one I new about, but I missed it. The page has a main model that is an aggregate model. It has two other models that have conditions on them of “in a field in any row from another model”. The problem is that the target model is an aggregate model and aggregate models have aliases. The builder doesn’t recognize that so it brings up option for you to choose actual object fields. So to fix this, you need to go into the xml and edit the field name to the alias name. I did that for one of the two secondary models, but forgot for the other one. So, it was the fact that I had a condition on a secondary model that referenced an object field on an aggregate model instead of the alias that was causing the load data on page load issue. Weird…