So I never really looked at this, but apparently the summations work by modifying your BAQ and running it??? It seems like first it sums based on data loaded into the client and then it runs a modified version of the BAQ to calculate and override this first value? So its overriding my BAQ select statement with this automatically generated garbage that is casting my decimal fields to BIGINTs

@Olga Are you familiar with how any of this works or is it outside your area of knowledge?
No. From what I see they are trying to move calculations to server, instead of doing it on the client.
Which is understandable, they are trying to find a solution for the case when you put in the BAQ millions of rows and expect it to work fast in the browser
Virtual grid with partial results.
I don’t believe this will work in many cases and apparently it does not.
But I don’t know how to make it working fine without it either.
I can’t imagine how millions of CSS rules on a web page for a grid presentation can compete with an OS-specific UI library in the smart client.
Good thing I am not in the UX library team ![]()
Thanks for the response @Olga , appreciate your honesty. Besides the video and trace, do you have any recommended verbiage for my support case?
If it is only rounding problem then I guess it is easy to fix with just reporting it.
If your field is decimal, there is no explanation why SUM should become integer. Just add this screenshot.
Technically its changing the case on my name as well, but I don’t care about that as much. Less likely to cause a real business error.
What could possibly go wrong, executing arbitrary SQL sent from a browser session.
BAQ already transferred the full results before the grouping request. Javascript’s native .groupby() will always outperform reimposing any entire query load and transfer.
Decimal → any integer type does not round, it truncates. The development team has vigorously disagreed with this, but it’s really important to continue insisting to them that verifiable core principles are true, because this particular misunderstanding applied in a domain that handles currency causes measurable harm.
well, you can summon Brian and explain it to him ![]()
I doubt we have enough mana for that big of a summon, but I suppose its worth a shot.
hey @bconner you in a BORING meeting rn and wanna explain this to us?
Ok I’ve been summoned ![]()
We’ve read the thread, what I don’t see in here is a case or issue report that you all would like us to review - that’s what we need here. I presume they’re entered and making their way to us (or have already).
If any of you want to DM me a case # or prb that’s in the works we will get involved in the back end with support and review.
CS0005301819
Created at 9:30 - don’t think its been assigned yet so I doubt you would have gotten anything on it
not a problem. if we know of one that’s early in stages that needs to be accelerated we’ll just reach out to support preemptively and offer to do that with them if needed. Will have someone give this a look shortly.
Thanks for coming in Brian. I mentioned the summation issues in this ticket, it’s mostly about the auto-expanding of groups since 2025.2.10 release CS0005300687
Edit: I also created this one focused on the summation issue: CS0005302290
Thanks Brian. Under a lot of stress here so please forgive any salty comments.
If you’ve never heard a salty comment about your work, you are probably not engineering anything that matters I often say
no worries.
Adding CS0005295839 to the list.
Is there a way to read other companies Case files to see if you have a similar issues? Everywhere I look it up on Epicare I don’t see these tickets and didn’t want to generate another one if there is already one in progress I could tie to or follow.
That’s how they determine how bad the problem is. So if you are having the same problem, open another ticket.
Bet. Starting to see why they try to tie to PRB’s and walk away from the issue which would work if you actually could ever get an update on a PRB.
