unnecessary Auto rounding

[DonLV]

Hi friends. Although I am writing here for the first time, in the last months I have spent a lot of time with you.

Now I am facing a problem that I can't solve on my own.

When I transfer data from one cell to a new row in another table (decimal) they are first rounded down in the original table and transferred in the same incorrect form to another table.

Rounding occurs at the moment when the bot is triggered send to the archive (deal status completed)

(Ex. Data before trigger 4,754 after trigger start change to 4,000)

I have a neighboring cell, from the same line, which I also transfer to another table by trigger. She also decimal. And there are no problems with her, she always remains in the right form.

I would be grateful for any hints🙏

[WillowMobileSys · Accepted solution]

First, it is important to know your locale to understand if the comma is a thousands separator or the decimal position.  I'll assume the later.

Confirm that all of the columns involved are indeed defined as Decimal AND that the number of Decimal Digits is either NOT set or set to an appropriate number.

To me it sounds like you are moving a decimal value into a column defined as Number.  Doing so, I believe, truncates the decimal digits.

[DonLV]

thanks for the answer.

Yes, that's what I've been watching the last two days. I checked the format of the cells in the source table and the table that I am transferring data. In each of them decimal with three 0 after the decimal point. 

I also changed the language/local settings in the table and the application to the same values. but it still didn't give me the desired result.

Let me remind you that I am transferring a whole string and other decimal data that I am transferring with the same action work correctly.

It also works correctly during other statuses in all cells . But as soon as the trigger fires in the original table in which everything showed correctly, one decimal value is first rounded and the rest are not.

[WillowMobileSys]

When you say the "value is first rounded", how do you know its rounded vs truncated vs converted?   

Since you've checked the data types and all looks good there, then we need to look at how you are "transferring" the value.  Using the word "transfer" implies you are likely doing more than just a copy.

Could you provide images of the process you go through to "transfer" the value?

[DonLV]

I had to redo the application again to get this error again and understand why it happens. At least thanks to this, I improved the data structure a little)

My cell was calculated using a formula in which several NUMBER values ​​take part. Regardless of the fact that the cell itself is set to DECIMAL and the formula during editing showed the correct result (decimal), after saving, the result returned NUMBER.

Thanks for the tip, have a great day😎👍

[WillowMobileSys]

Yes, that would be expected behavior.  If any of the "sub"-expressions return NUMBER type they will behave that way, passing on an appropriate NUMBER value to the next portion.  By the time the execution gets to the outer portion of the expression, the value could have been "translated" giving an unexpected result.  This can be avoided by making sure all calculations are done in the context of DECIMAL.  If you have a NUMBER column used in the calculation, wrap it with a DECIMAL() function.  If using any Literal values - use 2.0, 3.0 or 4.0, etc instead of 2, 3 or 4, etc.

Just a side note,  we might have been able to save you many hours of unnecessary reworking of the app if only we could have seen the  expression or process used to derive the "bad" value. 

On the bright side, as you said, you were able to improve things AND get much more intimate with the AppSheet features.  Maybe more than you wished?!?!

Glad you figured it out and good luck with the rest of your implementation!

[DonLV]

I have grouped two actions that are taken when the status changes to successfully. with these actions I set the closing date (works well) and the second action is transfer to the archive (add a new row to another table using this data)

These two tables are the same, so I just repeated the names of the columns (I double-checked their correctness many times). All this works as it should. Except one cell of 3 (who have type decimal)

I'm not sure if this is rounding, because the change is always down, no matter what the first decimal point is, more than 5 or less.

[WillowMobileSys]

Ok.  It could be a bug.  But I highly suspect it's something in the implementation.  Without seeing what's implemented it's hard to help.

[DonLV]

All my formulas work correctly because everything is calculated and displayed correctly before the trigger fires. location settings are also correct, since the rest of the data, including decimal are transferred and displayed correctly. 

I think that this bug may be related to the fact that I renamed the column names while working on the application from eng to ukr language.

Of course i always "regenerate the structure" after all this changes, and all another data work correctly.

I don’t know what exactly I can show for analysis, the screen where this cell value is decimal in two tables? or screenshot where column1 = [column1] in my trigger "archiver". I no longer have difficulty working elsewhere in my application🤷🏻‍♂️

[Steve]

Fix for expression giving 0% or missing decimal pa... - Google Cloud Community