Ceci est un article technique (bases de données SQL), n’hésitez pas à l’ignorer si ça ne vous intéresse pas 🙂

Depuis quelques jours nous galérons avec mon équipe à identifier une anomalie de traitement plutôt pénible dans l’ETL qui charge tous les soirs le chiffre d’affaire.

Nous avons enfin identifié l’erreur: le compte de service qui exécute le chargement le soir est configuré en américain sur la production, alors qu’il est en français sur les plateformes de développement. C’est dommage lorsqu’une date de bascule au 1er mai est interprété comme le 5 janvier en production. En effet le 05/01/2011 devient 01/05/2011 avec un format de notation américain.

Sachant que changer le paramétrage d’un compte de service en production peut prendre 3 ans de conflits politiques entre les différentes équipes (pour 2 minutes d’implémentation), nous avons décidé de faire évoluer les requêtes SQL pour qu’elles n’utilisent plus aucune conversion implicite.  L’objectif c’est de rendre le code insensible aux paramètres de langue.

En gros en SQL ça veut dire que ça c’est interdit: CAST(‘2011-05-01’ AS DATETIME), de même que référencer directement une date en chaîne de caractère : WHERE MonDateTime = ’05/01/2011′

A la place on doit faire ça : CONVERT(DATETIME,’01/05/2011′,103), ou ça : CONVERT(DATETIME,’2011-05-01′,102). En utilisant CONVERT, on peut préciser le format de la date de manière explicite: 103 pour JJ/MM/AAAA et 102 pour AAAA-MM-DD.

Ne laisser aucune conversion implicite (date ou autre) est définitivement une bonne pratique qu’il ne faut pas oublier. Pour les dates, c’est aussi une info qu’il faut savoir transmettre aux utilisateurs et MOA qui requètent les bases en SQL.

Pour plus de détail:

• MSDN : CAST et CONVERT
• Le guilde ultime des datetime dans SQL Server