We have a datasource field defined as type=“float”. In the DB2 iSeries SQL table the field is DECIMAL(17,10) 17 digits maximum, 10 to the right of the decimal point. When we make a fetch request, the value in the SQL table is .8196721311, but the value that displays in the FloatItem is 0.8196721076965332. We also have a floatPrecision validator with precision=“10” so the user gets an error message without having made any change to the value.
We’re using getAttributeAsFloat() to set the value in the ValuesManager used by the form.
Can you take the first few steps to determine where the lost of precision occurs: log it on the server, look in the RPC tab, log it on the client.
The RPC tab shows the response coming back with the correct precision -
CURAERU:0.8196721311
We’re then calling ValuesManager.setValue(“AnotherField”, response.getData()[0].getAttributeAsFloat(“CURAERU”)) and the field displays the additional precision.
Sorry. Should have mentioned SmartClient Version: SC_SNAPSHOT-2011-04-22/PowerEdition Deployment (built 2011-04-22)
I’m running in debug and right after this line
myValuesManager.setValue(“HCRT”, response.getData()[0].getAttributeAsFloat(“CURAERU”));
If I inspect myValuesManager.getValue(“HCRT”) it shows the correct precision as does response.getData()[0].getAttributeAsFloat(“CURAERU”). However, the FormItem displays the extra precision.
I can work around the problem by using getAttribute instead of getAttributeAsFloat. That sets the ValuesManager value to a String instead of a Float but it doesn’t seem to have any adverse effect, although I would like to know the correct way to handle float fields in this case in case we’re doing something wrong.