Poursuivons avec FORMAT(), qui est une extension de CONVERT(), puisqu’elle est plus ouverte aux différentes cultures … et beaucoup plus !

Tout d’abord, la syntaxe :

FORMAT (valeur, format [, culture ])

Comme avec PARSE() :

– la nouveauté c’est qu’on peut formater une valeur suivant une culture (33 cultures disponibles !)
– les types supportés par cette fonction : bigint, int, smallint, tinyint, decimal, numeric, float, real, smallmoney, money, date, time, datetime, smalldatetime, datetime2 et datetimeoffset.
– on ne peut pas utiliser PARSE() pour exécuter une requête sur un serveur distant, car celle-ci dépend du .NET Framework 3.5 SP1 , et que rien ne garantit qu’il est présent sur la machine distante.

On remarquera que les types de données de chaînes de caractère, comme pour PARSE(), ne sont pas supportés.
Dès lors, on ne peut pas s’attendre à pouvoir passer une date au format ISO dans une chaîne de caractères, et que cela fonctionne :

=> Formatage des dates

Commençons avec quelques exemples sur les dates, qui sont généralement assez recherchés.
Voyons sans la culture d’abord :

Et avec la culture :

On peut maintenant apprendre les bases d’une langue tout en codant

En revanche le formatage composite n’est pas directement supporté :

Attention donc, car les lettres qui correspondent à des parties de date sont automatiquement remplacées, sans qu’une erreur ne soit levée.

Essayons d’éviter ces lettres :

Mais il s’agit là d’un jeu dangereux.
Voyons si on peut les échapper. Est-ce que le classique anti-slash va fonctionner ?

Il faut reconnaître que c’est assez tortueux pour ne pas dire spaghetti.
Par extension, on pourra créer une fonction en T-SQL qui effectue automatiquement l’échappement de ces caractères …

=> Examinons maintenant les formats raccourcis :

Attention donc à la casse dans les formats !
On notera que le zéro non-significatif disparaît au format Français, mais demeure au format Anglo-saxon.

J’ai trouvé ceux-ci à tâtons. Voyons les dans leur ensemble :

On voit donc que pour le formatage de données :

– numériques, la casse du format court n’a pas d’importance
– numériques, on peut ajouter un chiffre au format court qui indique soit le nombre de décimales, soit la largeur de la mantisse
– numériques de devise, la culture change bien évidemment le résultat
– de date, la casse est importante, de même que la culture

=> Étudions les devises plus en détails :

On voit que les formats de devises sont rigoureusement respectés, notamment en ce qui concerne les points et les virgules : les anglo-saxons utilisent la virgule comme séparateur des puissances de 10 multiples de 3, alors que les Latins utilisent le point; et inversement pour les parties décimales.
De même la prise en compte des pays membres de la Zone Euro ont tous leur devise préfixée ou suffixée par le symbole €, alors que le Royaume-Uni et la Suède, qui n’en sont pas membres, ont bien évidemment conservé respectivement les symboles de la Livre Sterling et de la Couronne Suédoise.

Une petite remarque : en Arabe, la notation retournée par SQL Server n’est strictement identique à ce que l’on observe rien qu’en collant cette valeur de fenêtre de résultats dans la fenêtre de requêtes de SQL Server Management Studio :

J’ai essayé de faire traduire automatiquement par Google Translate, mais le résultat retourné est R.. Q. 1,234.56.
Si vous pouvez expliquer ce qui s’est passé, n’hésitez pas à poster un commentaire !

=> Les masques pour les valeurs numériques

Les masques permettent de spécifier le nombre de décimales pour une valeur numérique, et si l’on en a besoin, d’ajouter des symboles dans la valeur formatée à l’aide de la position :

Dans les colonnes exemple_2 et exemple_10, on a respectivement placé :

– une virgule avant les trois derniers chiffres de la partie entière de la valeur décimale
– un pipe avant les deux derniers chiffres de la partie entière de la valeur décimale

Dans la colonne exemple_11, l’antislash étant un caractère d’échappement, il y a donc un symbole dièse qui sera intercalé entre le dernier et l’avant-dernier chiffre de la partie entière de la valeur décimale.

De la même façon que ce que nous avons vu avec les formats courts, on peut aussi préciser le nombre de chiffres significatifs de la partie décimale d’une telle valeur.
Si le nombre de chiffres significatifs de la partie décimale :

– est plus petit que celui de la valeur passée en paramètre, alors la valeur formatée est arrondie
– est plus grand que celui de la valeur passée en paramètre, alors la valeur formatée est suivie d’autant de zéros que la différence entre le nombre de chiffres significatifs de la partie décimale et le nombre de chiffres de la partie décimale du masque de formatage.

Bon FORMATage de données à tous !

Commençons avec la fonction PARSE() …

La syntaxe d’utilisation de cette fonction est la suivante :

PARSE('<uneValeur>' AS <data_type> [USING '<culture>'])

La nouveauté c’est la possibilité de formater une valeur suivant une culture, et ce n’est pas moins de 33 cultures qui sont disponibles !
De façon générale, cette fonction est une extension de ce que l’on peut faire avec CONVERT().
Rappelons dans les deux cas qu’il s’agit de fonctions de formatage de données.

On notera que :

– data_type est limité aux types suivants : bigint, int, smallint, tinyint, decimal, numeric, float, real, smallmoney, money, date, time, datetime, smalldatetime, datetime2 et datetimeoffset.

– On ne peut pas utiliser PARSE() pour exécuter une requête sur un serveur distant, car celle-ci dépend du .NET Framework 3.5 SP1 , et que rien ne garantit qu’il est présent sur la machine distante.

Faisons quelques essais !

SELECT PARSE ('100.000' AS int)

Alors qu’un SELECT CONVERT(int, '100.000') :

Essayons un SELECT PARSE('Lundi 16 Avril 2012' AS datetime USING 'fr-FR')

Voyons au format Anglo-Saxon : SELECT PARSE('Monday 16 April 2012' AS datetime USING 'en-US')

Quid du format que l’on nous a donné à l’école ? SELECT PARSE('Monday, April 16 2012' AS datetime USING 'en-US')

En revanche SELECT PARSE('Monday, April 16th 2012' AS datetime USING 'en-US')

Essayons SELECT PARSE('April, 16 2012' AS datetime USING 'en-US')

Voyons avec une date du calendrier Grégo-Thaï : en effet, le calendrier Grégo-Thaï à 543 ans d’avance sur le calendrier Grégorien :
SELECT PARSE(N'16 เมษายน 2555' AS datetime USING 'Th-TH')

Et avec des variables ?

Et dans une table :

Vous vous demandez s’il sera possible de retourner une valeur décimale avec le symbole de la devise suivant une culture ? la réponse est oui : avec la fonction FORMAT(), que nous verrons au prochain épisode

Bon formatage de données !

ElSüket