PARSE() vs TRY_PARSE() dans SQL Server :Quelle est la différence ?

Dans SQL Server, le PARSE() et TRY_PARSE() les fonctions sont utilisées pour traduire une valeur dans un autre type de données. Ils font essentiellement la même chose, à une exception près; comment ils gèrent les erreurs.

Si PARSE() échoue lors d'une tentative d'analyse vers un type de données différent, il renverra une erreur. Si TRY_PARSE() échoue, il retournera NULL .

Exemple 1 - Tout d'abord, les similitudes

Voici un exemple qui montre comment les deux fonctions renvoient le même résultat lorsqu'elles réussissent à analyser la valeur dans le type de données requis :

SELECT 
    PARSE('Fri, 8 June 2018' AS date) AS PARSE,
    PARSE('Fri, 8 June 2018' AS date) AS TRY_PARSE;

Résultat :

+------------+-------------+
| PARSE      | TRY_PARSE   |
|------------+-------------|
| 2018-06-08 | 2018-06-08  |
+------------+-------------+

Comme prévu, ils renvoient tous les deux exactement le même résultat.

Mais voyons ce qui se passe lorsqu'ils sont incapables d'analyser la valeur avec le type de données requis.

Exemple 2 – Lorsque PARSE() échoue

Voici un exemple de ce qui se passe lorsque PARSE() est incapable d'analyser une valeur vers une autre valeur :

SELECT PARSE('Next year' AS date) AS Result;

Résultat :

Error converting string value 'Next year' into data type date using culture ''. 

L'opération échoue car je n'ai pas fourni de représentation valide du type de données demandé. En d'autres termes, PARSE() impossible de convertir Next year dans un rendez-vous type de données comme demandé.

Exemple 3 – Lorsque TRY_PARSE() échoue

Voici un exemple lorsque nous essayons d'analyser la même valeur avec TRY_PARSE() :

SELECT TRY_PARSE('Next year' AS date) AS Result;

Résultat :

+----------+
| Result   |
|----------|
| NULL     |
+----------+

L'analyse échoue toujours, mais elle renvoie NULL au lieu d'une erreur.

Exemple 4 - Utilisation de TRY_PARSE() avec une instruction conditionnelle

Nous pouvons prendre TRY_PARSE() et testez sa valeur de retour. Si c'est une valeur NULL, nous pouvons renvoyer une chose, si c'est une valeur non NULL, nous pouvons en renvoyer une autre :

SELECT 
    CASE WHEN TRY_PARSE('Next year' AS date) IS NULL
        THEN 'Conversion failed'
        ELSE 'Conversion succeeded'
    END
AS Result;

Résultat :

+-------------------+
| Result            |
|-------------------|
| Conversion failed |
+-------------------+

Exemple 5 - TRY_PARSE() avec erreur

Juste parce que TRY_PARSE() n'entraîne pas d'erreur dans les exemples ci-dessus, cela ne signifie pas qu'il jamais entraîne une erreur. Il y a des moments où vous pouvez toujours obtenir une erreur lors de l'utilisation de cette fonction.

Par exemple, vous obtiendrez une erreur si vous fournissez une valeur non valide comme culture argument :

SELECT TRY_PARSE('Next year' AS date USING 'Mars') AS Result;

Résultat :

The culture parameter 'Mars' provided in the function call is not supported. 

Quelques notes sur ces fonctions

Voici quelques points que Microsoft a à dire sur ces fonctions :

• Il est recommandé d'utiliser PARSE() et TRY_PARSE() uniquement pour la conversion de type chaîne en type date/heure et nombre. Pour les autres types de données, utilisez CAST() ou CONVERT() .
• Ces fonctions reposent sur la présence de .NET Framework Common Language Runtime (CLR).
• L'analyse de la valeur de la chaîne entraîne une certaine surcharge de performances.
• Ces fonctions ne seront pas déportées puisqu'elles dépendent de la présence du CLR. Essayer de mettre à distance une fonction qui nécessite le CLR provoquerait une erreur sur le serveur distant.