Hey there,
I’m testing changing a decimal column from two places to three:
Then after a regen, it looks okay here in this updatable BAQ:
But after the update the number is rounded to two places:
Did I miss a step?
Thanks,
Joe
Is the number stored as two decimals? As if the Update rounded it to 9.13, and that’s what got stored. Check it with SQL.
Did you redeploy the uDashboard after changing the format in the BAQ designer?
I do not believe you can change that after the initial creation. I have always had to recreate a column if I needed to change something like that.
Have you checked to see if you can make changes to it through Extended Properties?
with what @jkane said in mind, can you use the extended properties on a UD table?
We had to change the number of digits shown in the “next order number” field as it defaults to being 6 digits wide, and our next number needed to be 7 digits.
That’s what it looks like to me–I can enter three digits to the right of the decimal, but after I save it the number has been rounded to two places.
I’m testing the update in the BAQ, and just to make sure, I deleted the table and readded after the regen.
It might not be possible to change. Here is what the Extended Properties shows. Only the default format shows, and it’s read only.
Kind of makes sense that it’s read only, as you’re able to set it in UD Table Maintenance. One would think that it should match what is shown in UD Maint.
Well, there’s Decimals way down in the bottom right, but still greyed out.
Did you confirm that the data being stored goes to 3 decimal places, via a SQL query? Just want to rule out that the data isn’t getting rounded before it is written to the table.
No, I don’t have access to the SQL server. And I’m not a SQL guy.
So back to the original point… You have a UBAQ, that when you get records it shows 3 decimal places. If you enter a value like 9.125 and update, the BAQ designer shows “9.130” after the update. Correct?
If you fetch the records again, it shows “9.130”?
Can you enable a trace, and see what the dataset contains during the execution? Let’s see if 9.130 is what’s being written on the update. Or if it is actually sending 9.125.
I trace just before the Update:
<paramDataSetChanges>
<paramDataSet name="queryResultDataset" useDataSetNbr="0">
<changedValue tableName="Results" rowState="Modified" rowNum="0" colName="UD09_OurReqQty_c"><![CDATA[9.125]]></changedValue>
. . .
<returnValues>
<returnParameter name="result" type="System.Data.DataSet">
<QueryResultDataSet>
<Results>
<UD09_Company>TCF</UD09_Company>
<UD09_Key1>DS-POGEN</UD09_Key1>
<UD09_Key2>HEADER</UD09_Key2>
<UD09_Key3></UD09_Key3>
<UD09_Key4></UD09_Key4>
<UD09_Key5></UD09_Key5>
<UD09_OurReqQty_c>9.130</UD09_OurReqQty_c>
Whatever it is that’s doing the rounding, the three-decimal place number goes in and the two-decimal place number comes out.
I’m looking at this for an instance where chemical tests are run, and the number of decimals might change from time to time. I’m thinking about going a different route in my application, anyway, but it would be nice to know if this is possible.
Thanks,
Joe
@jdtrent the controls in screens and BAQs will have absorbed the original format. Look at your BAQ’s number format
Yes, good idea. I deleted the table and readded after the regen to make sure it got the right format:
Thanks,
Joe
Just re-read what you sent in the trace. I would say type in SQL did not full update. Should be easily fixed manually but you would need SQL access to do it. My guess it’s still defined in SQL as DECIMAL(20,2) instead of DECIMAL(20,3).
Hindsight create everything at 9 places and visually format in the system.
2 Likes
I don’t know the details of how decimals are stored in a SQL table, but I’d have bet against them being rounded to the “format” prior to to being written.
Just for shits and giggles, try the following:
- Add a calc field to your BAQ with the expression
UD09.OurRecQty_c + 0.002 - Set the OurRecQty_c field to 9.120 and update.
After the update your OurRecQty_c should show 9.120, and the calc field should show 9.122
Do the update again but with the value 9.123. That should still display as 9.120 after the update. What will be interesting to see is if the calc field displays 9.122 or 9.125.
Just tested it our testing system. Updated decimal value and formats updated and database type updated as well. Scale was 4 it’s 9 now.
I have run into the same issue in the Classic screens on Kinetic 2021.2. Epicor has stated this bug is fixed on the Kinetic screen side.
My issue was with a Classic quick search still showing two decimals even though I changed it to 5 and did the database model regen. This was corrected in the Kinetic quick search.
I have a quick search that the decimal value has not changed on and it only shows 2 decimals. I think that’s some strange limitation of quick search in classic in general maybe, not really related to changing from 2 to 5 in UD maint.