---
title: "Floating Along"
url: https://daily.dev/posts/floating-along-5oio0yq5h
source_url: https://thedailywtf.com/articles/floating-along
type: article
source: "The Daily WTF"
published: 2026-08-18T10:45:34.854Z
updated: 2026-08-18T10:45:54.204Z
tags: ["microsoft-sql-server", "powershell", "sharepoint"]
reading_time: 2
upvotes: 0
comments: 0
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Floating Along

**[The Daily WTF](https://daily.dev/sources/thedailywtf)** · 2 min read · 0 upvotes · 0 comments

## Summary

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.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://thedailywtf.com/articles/floating-along>

## 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._

## Similar posts on daily.dev

- [Simplifying Schema Design with DECFLOAT: One Numeric Type to Rule Them All](https://daily.dev/posts/simplifying-schema-design-with-decfloat-one-numeric-type-to-rule-them-all-0ur2odeqk) · Snowflake Community · 0 upvotes · 0 comments

---

Tags: [#microsoft-sql-server](https://daily.dev/tags/microsoft-sql-server), [#powershell](https://daily.dev/tags/powershell), [#sharepoint](https://daily.dev/tags/sharepoint)

[View this post on daily.dev](https://daily.dev/posts/floating-along-5oio0yq5h)