We offered ten decimal places and stored six. Nothing said a word.

A customer set a Decimal column to ten places, typed 0.1234567891, and got 0.123457 back. The grid showed no error and no red cell. It said saved, and it had saved six of the ten places.

That bug was ours. The reason it stayed quiet belongs to SQL Server: the same rule runs in every database you have, and the usual decimal vs float answers skip it.

What went wrong

The column setup let you pick 0 to 10 decimal places. The column that holds every Decimal value in Primentra was DECIMAL(18,6), so it had room for six. Every write cast the value to that type, and SQL Server did what it always does with such a cast:

SELECT CAST(0.1234567891 AS DECIMAL(18,6));
-- .123457   (no error, no warning)

SELECT CAST(1234567890123 AS DECIMAL(22,10));
-- Msg 8115: Arithmetic overflow error
-- converting numeric to data type numeric.

Put the two results next to each other. Too many digits before the point and SQL Server stops you. Too many after the point and it rounds and carries on. Our tests checked that a value got saved. None of them compared it with what was typed, so they all passed.

Version 1.2026.10.5 changed the column to DECIMAL(22,10): 12 digits before the point, as before, and 10 after. A cell edit, a paste, a file import, staging, an approval, the REST API and a business rule all store the value as typed now. The server also refuses a setting outside 0 to 10 places, so the screen cannot offer more than the database keeps.

Values that older versions rounded stay rounded. The digits were lost before they reached the table, and an upgrade cannot invent them.

Decimal vs float in two queries

DECIMAL(p,s) stores exact base-ten digits: p in total, s of them after the point. Whatever fits comes back exactly. Whatever does not fit after the point gets rounded, as above.

FLOAT stores the nearest binary fraction. Most decimal values have no exact binary form, so you get something very close:

SELECT CAST(0.1 AS FLOAT) + CAST(0.2 AS FLOAT) - 0.3;
-- 5.5511151231257827E-17

SELECT CAST(0.1 AS DECIMAL(5,1)) + CAST(0.2 AS DECIMAL(5,1));
-- .3

For master data the choice is easy. Someone typed the price, the VAT rate, the conversion factor or the tolerance on a drawing, and they expect the same digits back. Use decimal. Float is for measurements across a huge range where a tiny relative error does not matter, and a reference table rarely holds those.

Decimal fixes the column. A value passes through several layers before it gets there.

Four places a digit leaks

The JSON row catches people out. A browser, Node.js and most API clients read every JSON number as a double, which is a float under another name. Send 1234567890.1234567891 and the client reads 1234567890.1234567. Pass that same value through a float column and it comes back as 1234567890.1234567165. The decimal column was exact all along, and the client had already changed the value before it arrived.

So the fix had to reach those layers as well. The REST API takes decimalValue as a number or as a string, and a read with ?decimals=text returns the exact value as a string. An XLSX export writes a Decimal of more than 15 digits as text, so Excel cannot shorten it when someone opens the file. And a value filter now lists 1.0000000001 and 1.0000000002 as two entries. It used to merge them.

Check your own columns

You will not hear any of these leaks, so go and look. Two queries to start with:

-- Float and real columns: should any of them be decimal?
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, DATA_TYPE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE DATA_TYPE IN ('float', 'real')
ORDER BY TABLE_SCHEMA, TABLE_NAME;

-- Decimal columns and their scale: does a screen offer more?
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME,
       NUMERIC_PRECISION, NUMERIC_SCALE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE DATA_TYPE IN ('decimal', 'numeric')
ORDER BY NUMERIC_SCALE;

The third check has no query. Read the parameters in your stored procedures and load packages. A @Rate DECIMAL(18,4) in front of a DECIMAL(18,8) column rounds just as quietly as a narrow column, and it is much harder to find.

Then type a value with every place filled into each screen and each feed, and compare what comes back, digit by digit. Saved and stored as typed are two different claims. We tested the first one.

In Primentra the number of places is a setting on the column. Attributes and data types lists what each type holds. If a column needs a hard limit, a business rule can refuse a value with more places than you allow, so the person typing gets a message instead of a rounded number.

Common questions

Upgrading to 1.2026.10.5? Make a backup first. The upgrade rewrites the column that holds every value, and on a large database that takes minutes.