Floating Along
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
A developer recounts migrating customer document metadata from on-premises SharePoint to SQL Server using PowerShell and SqlBulkCopy. A subtle naming mismatch between .NET's 'float' (single-precision) and SQL Server's 'float' (double-precision) type caused large customer numbers to lose precision during the copy, silently corrupting the last few digits of some records. The bug slipped past testing and was only caught during the full data load, requiring a post-hoc patch of affected numbers.
Questions this post answers
Why does SQL Server's float type not match .NET's float type when copying data with SqlBulkCopy?
SQL Server's float type is double-precision, equivalent to .NET's double, not .NET's float, which is single-precision. Using float(24) in SQL Server gives single-precision instead. Mapping a SQL Server float column to .NET float in a script causes precision loss, which can silently corrupt large exact values like 10-digit customer numbers during bulk copy operations. Anyone migrating numeric data between SQL Server and .NET can hit this exact type mismatch; daily.dev surfaces write-ups like this before they cost you a data patch.
Why should customer numbers not be stored as a Number field in SharePoint?
SharePoint Number fields are stored internally as doubles, which can represent 10-digit customer numbers precisely on their own, but downstream conversions between different floating-point types risk truncating or altering digits. Storing identifiers like customer numbers as text avoids this class of precision bug entirely, since exact values with no arithmetic meaning are better represented as strings. Teams designing schemas for exact identifiers can compare storage type tradeoffs like this on daily.dev before picking a data type.