Un contributeur du Daily WTF, John F., raconte une migration subtilement ratée. Son entreprise avait cédé une partie de son activité et devait fournir des documents clients et leurs métadonnées, stockés dans un SharePoint local. Le plan : extraire les métadonnées dans une base SQL Server.

Un collègue avait commencé avec l'outil ETL de Microsoft, SSIS, qui a généré le schéma de la base. John est passé à PowerShell pour plus de contrôle et a utilisé System.Data.SqlClient.SqlBulkCopy pour la vitesse, ce qui exigeait de déclarer des types .NET exacts dans son script.

L'un des champs était le numéro client : jusqu'à dix chiffres, souvent précédés de deux zéros. Quelqu'un l'avait autrefois stocké dans un champ Number de SharePoint, qui est en interne un Double. La double précision représente exactement des nombres à dix chiffres, jusque-là tout va bien. Le piège tenait au nommage. Dans SQL Server, le type double précision s'appelle float ; pour la simple précision, il faut écrire float(24). John l'ignorait et a mappé la colonne float sur le type .NET float, donc simple précision.

Les doubles issus de SharePoint étaient silencieusement tronqués à l'insertion. La plupart des enregistrements ont survécu, mais les grands numéros clients ont vu leurs derniers chiffres modifiés. Les testeurs n'ont rien remarqué. Le chargement complet, si. L'équipe a dû produire la liste des numéros altérés et corriger les données après coup. La chute : d'une plateforme Microsoft vers une plateforme Microsoft avec des outils Microsoft, et les noms de types l'ont quand même piégé.