Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Fonctionnement de TRY_CONVERT() dans SQL Server

Dans SQL Server, le TRY_CONVERT() La fonction est très similaire à la fonction CONVERT() fonction, sauf que TRY_CONVERT() ne renvoie pas d'erreur si la conversion échoue (CONVERT() Est-ce que).

Au lieu de cela, le TRY_CONVERT() la fonction renvoie NULL si la conversion échoue.

Il y a cependant des occasions où TRY_CONVERT() renverra une erreur.

Syntaxe

La syntaxe ressemble à ceci :

TRY_CONVERT ( data_type [ ( length ) ], expression [, style ] )

expression est l'expression à convertir, data_type est le nouveau type de données, et length est une longueur facultative pour le nouveau type de données.

Le style facultatif l'argument peut être utilisé pour spécifier comment la fonction doit traduire l'expression argument. Par exemple, vous pouvez utiliser cet argument pour spécifier le format de date.

Exemple 1 – La conversion réussit

Voici un exemple de conversion d'une chaîne en décimal :

SELECT TRY_CONVERT(DECIMAL(5,2), '007');

Résultat :

7.00

Dans ce cas, la conversion a réussi.

Exemple 2 – La conversion échoue et renvoie NULL

Voici un exemple d'échec de la conversion et NULL en cours de retour :

SELECT TRY_CONVERT(DECIMAL(5,2), 'Three');

Résultat :

NULL

La conversion a échoué, et donc NULL a été renvoyé.

À titre de comparaison, voici ce qui se passe lorsque nous utilisons CONVERT() au lieu de TRY_CONVERT() :

SELECT CONVERT(DECIMAL(5,2), 'Three');

Résultat :

Msg 8114, Level 16, State 5, Line 1
Error converting data type varchar to numeric.

Exemple 3 – La conversion échoue et renvoie une erreur

Il y a des occasions où TRY_CONVERT() renverra une erreur.

Si une conversion n'est explicitement pas autorisée, elle renvoie une erreur :

SELECT TRY_CONVERT(xml, 10);

Résultat :

Msg 529, Level 16, State 2, Line 1
Explicit conversion from data type int to xml is not allowed.

Exemple 4 – Le style Argumentation

Nous pouvons utiliser le style facultatif argument pour spécifier comment l'expression doit être traduite.

Exemple :

SET LANGUAGE British;
SELECT 
    TRY_CONVERT(date, '09/02/2030') AS "British",
    TRY_CONVERT(date, '09/02/2030', 101) AS "US",
    TRY_CONVERT(date, '09/02/30', 1) AS "US (short)",
    TRY_CONVERT(date, '20300902', 112) AS "ISO",
    TRY_CONVERT(date, '09.02.2030', 104) AS "German";

Résultat :

Changed language setting to British.
+------------+------------+--------------+------------+------------+
| British    | US         | US (short)   | ISO        | German     |
|------------+------------+--------------+------------+------------|
| 2030-02-09 | 2030-09-02 | 2030-09-02   | 2030-09-02 | 2030-02-09 |
+------------+------------+--------------+------------+------------+

Ici, j'ai défini ma langue sur British , puis a exécuté TRY_CONVERT() plusieurs fois, chacune utilisant un style différent argument (sauf pour le premier, qui utilise la langue par défaut de ma session - britannique).

Nous pouvons voir que l'argument de style affecte la façon dont l'expression est traduite.

Plus d'informations

Voir CONVERT() dans SQL Server pour plus d'exemples de conversion, et CONVERT() contre TRY_CONVERT() dans SQL Server pour une comparaison entre CONVERT() et TRY_CONVERT() .

Voir la documentation de Microsoft pour CAST() et CONVERT() pour des informations plus détaillées (la plupart s'applique également à TRY_CONVERT() ).