Back to all notes

C# / SQL

The numbers looked right. The types didn’t.

Written up September 22, 2026, from our original discussion.

An Entity Framework error sent me back to the database schema. The C# property was decimal. The SQL column was real.

I was moving some liner-sheet configuration into the database when I ran into this:

The specified cast from a materialized 'System.Single' type to the 'System.Decimal' type is not valid.

At first glance, that sounds like a conversion problem somewhere in the calculation. I was working with panel heights and quantities, so there were plenty of places to look. But the useful clue was the word materialized. The failure was happening while the database result was being turned into an object.

The mismatch was already there

The C# model used decimal. The database column used real. I checked both and, yep, they didn’t match.

SQL Server’s real maps to .NET’s Single, which C# calls float. SQL decimal maps to .NET Decimal. Both database columns can display a value that looks like a perfectly ordinary panel height. That doesn’t make them interchangeable when a data reader is filling a typed property.

Fix the contract before the calculation

The direction we settled on was to use a decimal column to match the model, with precision and scale chosen for the values the configuration needs to store. If the application uses generated database mappings, those need to agree with the schema too.

This is the small version of the mismatch, using a generic pricing property:

public decimal UnitPrice { get; set; }

That property needs a compatible mapping all the way back to the database. Adding a cast later in the calculation doesn’t help if loading the object fails before the calculation ever starts.

What I’m taking from it

I’d been focused on getting the sheet-selection rules right. Moving those inputs into a table introduced another piece to check: the database and the application need to agree about what each value is.

When I see this kind of error again, I’m going to compare the SQL type, the model property, and the mapping before digging through the arithmetic. In this conversation we identified the mismatch and agreed on the schema correction; I’m not treating that as a record of a completed production migration.

Reference: Microsoft’s SQL Server data type mappings.

Back to all notes