# Value coming from dataset by lookup is rounded on numeric data entry component?

**URL:** <https://forum.inductiveautomation.com/t/value-coming-from-dataset-by-lookup-is-rounded-on-numeric-data-entry-component/46469>\
**Category:** Ignition\
**Tags:** ignition80, perspective, scripting\
**Created:** [May 7, 2021, 10:14am UTC](https://forum.inductiveautomation.com/t/value-coming-from-dataset-by-lookup-is-rounded-on-numeric-data-entry-component/46469 "2021-05-07T10:14:23Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![berkay.cinar](https://avatars.discourse-cdn.com/v4/letter/b/b9bd4f/32.png) [@berkay.cinar](https://forum.inductiveautomation.com/u/berkay.cinar)\
**Post date:** [May 7, 2021, 10:14am UTC](https://forum.inductiveautomation.com/t/value-coming-from-dataset-by-lookup-is-rounded-on-numeric-data-entry-component/46469/1 "2021-05-07T10:14:23Z")

</div>

Hello

I have a dataset tag and lookup expression on numeric entry component is taking data from this dataset. In dataset values are float like 1.8 but when I read this into a component it is rounded to 2.

lookup({[TSW\_Production]Foaming/LineProductionData/TotalProductionData/ProcessParametersTable},{…/Label\_1.props.text},0,0,2)

This should read 1.8 but it read 2 how can I avoid this?

Thanks

---

<div class="post-metadata">

**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\
**Post date:** [May 7, 2021, 10:32am UTC](https://forum.inductiveautomation.com/t/value-coming-from-dataset-by-lookup-is-rounded-on-numeric-data-entry-component/46469/2 "2021-05-07T10:32:12Z")

</div>

Does the value resolve to 2, or does it resolve to 1.8 and shows 2 in the display? If the latter, how is the numeric input’s `props.format` key set up?

---

<div class="post-metadata">

**Author:** ![berkay.cinar](https://avatars.discourse-cdn.com/v4/letter/b/b9bd4f/32.png) [@berkay.cinar](https://forum.inductiveautomation.com/u/berkay.cinar)\
**Post date:** [May 7, 2021, 10:44am UTC](https://forum.inductiveautomation.com/t/value-coming-from-dataset-by-lookup-is-rounded-on-numeric-data-entry-component/46469/3 "2021-05-07T10:44:22Z")

</div>

it is read as 0,2 directly from the expression format is like this

0,0.##

---

<div class="post-metadata">

**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\
**Post date:** [May 7, 2021, 11:13am UTC](https://forum.inductiveautomation.com/t/value-coming-from-dataset-by-lookup-is-rounded-on-numeric-data-entry-component/46469/4 "2021-05-07T11:13:57Z")

</div>

This is sounding like a locale issue.

> [@\[BUG-13153\] Perspective NumericEntryField ignores selected locale](http://forum.inductiveautomation.com/t/bug-13153-perspective-numericentryfield-ignores-selected-locale/23364):
>
> In preview mode, the NumericInput field uses the systems locale when the field is focused and english when the field has no focus. Project properties - Perspective - Project locale: German NumericEntryField with default settings When the field has focus the displayed value is 12345,67 When leaving the field with Enter or Tab the field displays 12,345.67 Expected display value is 12.345,67 A client session in a browser shows the same behaviour and a label bound the value property shows 1234…

---

<div class="post-metadata">

**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\
**Post date:** [May 7, 2021, 11:16am UTC](https://forum.inductiveautomation.com/t/value-coming-from-dataset-by-lookup-is-rounded-on-numeric-data-entry-component/46469/5 "2021-05-07T11:16:21Z")

</div>

although after saying that, what if you set your format to 0,## ?

---

<div class="post-metadata">

**Author:** ![berkay.cinar](https://avatars.discourse-cdn.com/v4/letter/b/b9bd4f/32.png) [@berkay.cinar](https://forum.inductiveautomation.com/u/berkay.cinar)\
**Post date:** [May 7, 2021, 11:49am UTC](https://forum.inductiveautomation.com/t/value-coming-from-dataset-by-lookup-is-rounded-on-numeric-data-entry-component/46469/6 "2021-05-07T11:49:52Z")

</div>

Nope does not work, still rounds it to 2. I multiple the dataset values by 100 and then divide the lookup result by 100. It is an unneccessary way of doing it but only way I could figure it out.

Thanks for the help though Jordan

---

<div class="post-metadata">

**Author:** ![mcgheeiv](https://avatars.discourse-cdn.com/v4/letter/m/71c47a/32.png) [@mcgheeiv](https://forum.inductiveautomation.com/u/mcgheeiv)\
**Post date:** [May 7, 2021, 12:45pm UTC](https://forum.inductiveautomation.com/t/value-coming-from-dataset-by-lookup-is-rounded-on-numeric-data-entry-component/46469/7 "2021-05-07T12:45:17Z")

</div>

Try changing the noMatchValue value to a fraction, lookup(tag, lookup\_value, 0.0, 0, 2).

I would also recommend using the lookup and result column names instead of 0 and 2.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [May 7, 2021, 4:20pm UTC](https://forum.inductiveautomation.com/t/value-coming-from-dataset-by-lookup-is-rounded-on-numeric-data-entry-component/46469/8 "2021-05-07T16:20:00Z")

</div>

@mcgheeiv's got it - as the [documentation](https://docs.inductiveautomation.com/display/DOC81/lookup) notes:

> The type of the value returned will always be coerced to be the same type as the noMatchValue.

With a bare `0`, we have no way to know whether you're trying to specify an int, long, float, or double...so we default to integer, since it's most common. `0.0` will default to a floating point type (probably double, but I'm not sure off the top of my head). You could also do it explicitly, by wrapping your bare constant in a casting function, i.e. `toDouble(0)`.
