Sum operator not calculating correctly

A bit stumped with this one. I have a checkbook register app that adds up sums for transactions. For some reason, the Sum operator is not working as expected. I’ll share some screenshots below.

Adding some information for context. The error I show below is not happening for every user. My app has 2800+ users and 500,000+ transactions in the database.

This is what my setup is in Bubble:

This is the outcome:

The calculation here is wrong. It should be $1,017,127.11

To confirm this, I downloaded a CSV of all the transaction data for the account add added it up in Excel. The result from Excel? $1,017,127.11

Has anyone ever run into this issue before? I’m not sure what to do.

Hi there, @jordanryankennedy_as… is the calculation incorrect for every user? If so, does it look like there is a pattern to how it is incorrect across users?

It will be difficult (if not impossible) for anyone to help on this one without being able to take a look under the hood. If it’s not real data you are working with there, can you share a read-only link to your editor?


Hi @mikeloc — I’ve edited my post to add some context. No, the calculation is not incorrect for every user. Part of the issue when figuring out this issue is that there is no pattern that I can find. The calculations are seemingly wrong randomly.

Unfortunately I can’t give access to my Bubble as read-only because it has sensitive data.

Just out of curiosity, how are you getting the checking and savings sums that are showing in the second screenshot? Are they the sums of the transactions of a certain type created by the current user?

You wouldn’t happen to be :merging multiple lists (or otherwise doing Bubble list operators) and then summing, would you?

Because that will cause duplicate values to disappear.

This seems pretty easy to debug. Just print out the list you’re doing :sum on. You’ll surely find that list is not what you expect.

Note that the :sum operator doesn’t cause set-like collapse, but some other operators will.

Users create Transactions which have an Account field and an owner (“Created By”). To calculate an individual account I just “Do a search for” transactions with that particular account and calculate the sum of the “Amount” which is a number.

@Keith No, no :merging of multiple list. Just like you see in the screenshot, it’s just a simple “Do a search for” on transactions whose owner is the Curren user. I just :sum the “Amount” field, which is just a numbers input.

Yeah, that’s what I figured you were doing. It’s weird if the only difference between the account sums and the main sum is the removal of the account constraint. Any chance the conditional in the first screenshot is having an unintended effect on the sum?

So first, if @jordanryankennedy_as just prints the value of their Search for Transactions: each item’s Amount to a text element (or similar), they will (most likely) find that the entries here are not what they expect.

Which is to say, some of them will be missing.

As for possible explanations as for why some of them may be missing, some possible explanations include:

  1. Some of the Transactions were created by a different user than “Current User”. (The source of such Transactions would most likely be the system, which can create Things in no user context whatsoever and such Transactions will have an empty “Created By” field.) Do you have backend workflows that might create Transactions? (Or is it possible that some of your users have managed to create Transactions without being logged in or when identified as some different User (e.g., a temp usuer)?

  2. The list of Transactions in this case is so large that not all of them show up in the results of the Search and so a truncated list is present there and the :sum is the sum of the truncated list. (This is somewhat less likely as Bubble’s “Search for…” will properly retrieve at least 16,000-ish values in this way [having just tested that]. But I’m pretty sure I’ve been able to max out the number of returned values and this will probably vary by browser.)

HOWEVER, what I’m interested to know is how @jordanryankennedy_as 's subtotals are being computed. Are they also simple sums of searched-for Transactions?

As @jordanryankennedy_as notes, the values of the subtotals there do, in fact sum, to 1017127.11 and – if that value is correct AND the subtotals are correct AND being done by simple sums of search-for Transactions, then #2 is probably the explanation.

If you’re confident in your subtotals, @jordanryankennedy_as, why not just store those values and sum them. You could use List Shifter (for example, using the Custom List feature) to construct an un-de-duped list of numbers and then take the :sum of that.

But if you’re hitting some max list size problem, you’ll eventually hit it again as one of the subtotal Transaction sums goes haywire due to the same issue.

Yup, I was interested in that, too, which is why I asked the same question.

This topic was automatically closed after 70 days. New replies are no longer allowed.