Database.Guide

Parfois, vous avez rencontré les fonctions T-SQL PARSE(), CAST() et CONVERT() lorsque vous travaillez avec SQL Server et vous vous êtes demandé quelle était la différence. Ces trois fonctions semblent faire la même chose, mais il existe des différences subtiles entre elles.

Dans cet article, je vise à souligner les principales différences entre ces fonctions.

Comparaison

Voici un tableau qui souligne les principales différences entre les fonctions CONVERT(), CAST() et PARSE() de SQL Server :

	CONVERT()	CAST()	PARSE()
Définition officielle	Convertit une expression d’un type de données en un autre.	Convertit une expression d’un type de données à un autre.	Retourne le résultat d’une expression, traduite au type de données demandé dans SQL Server.
Valeur acceptée	Toute expression valide.	Toute expression valide.	String.
Valeur retournée	Deuxième argument, traduit au type de données demandé tel que fourni par le 1er argument.	1er argument, traduit au type de données demandé tel que fourni par le 2e argument.	1er argument, traduit au type de données demandé tel que fourni par le 2e argument.
Conversions prises en charge	Entre deux types de données quelconques.	De la chaîne de caractères aux types date/heure et nombre uniquement.
Accepte l’argument de style ?	Oui.	Non.	Non.
Accepte l’argument de la culture?	Non.	Non.	Oui.
Requiert .NET Framework?	Non.	Non.	Oui.

Quelques autres points en plus du tableau ci-dessus :

• La documentation Microsoft souligne que PARSE() ne sera pas remotée (puisqu’elle dépend de la présence du CLR). Remotter une fonction qui nécessite le CLR provoquerait une erreur sur le serveur distant.
• Il y a certaines valeurs que PARSE() peut traiter mais que CAST() et CONVERT() ne peuvent pas (par exemple, les chaînes utilisant certains formats de date).
• CAST() est incluse dans la norme ANSI SQL-92.
• Certains soutiennent que CAST() a de meilleures performances que les deux autres.
• Il y a une certaine surcharge de performance lors de l’analyse syntaxique des valeurs de chaîne. Par conséquent, PARSE() s’exécutera généralement plus lentement que les deux autres.

Vous trouverez ci-dessous des exemples de situations où chaque fonction serait la plus appropriée.

Quand utiliser CAST()

Un bon argument pourrait être fait pour utiliser CAST() pour tout scénario qui n’est pas listé ci-dessous. Comme mentionné, CAST() fait partie de la norme ANSI SQL depuis SQL-92, donc elle devrait être plus portable entre différents SGBD (si c’est une exigence).

De plus, certains soutiennent que CAST() a de meilleures performances que les deux autres (voici un article intéressant qui compare les performances entre les trois fonctions).

Cependant, il y a aussi des raisons valables pour lesquelles vous pourriez préférer (ou avoir besoin) d’utiliser CONVERT() plutôt que CAST().

Quand utiliser CONVERT()

La fonction CONVERT() peut s’avérer pratique lorsque vous devez utiliser l’argument style pour spécifier comment la date doit être formatée lors de la conversion entre une date et une chaîne de caractères. Voici quelques exemples:

DECLARE @date datetime2 = '2018-06-07 02:35:52.8537677';SELECT CONVERT(nvarchar(30), @date, 100) AS '100', CONVERT(nvarchar(30), @date, 101) AS '101', CONVERT(nvarchar(30), @date, 102) AS '102', CONVERT(nvarchar(30), @date, 103) AS '103';

Résultat:

+---------------------+------------+------------+------------+| 100 | 101 | 102 | 103 ||---------------------+------------+------------+------------|| Jun 7 2018 2:35AM | 06/07/2018 | 2018.06.07 | 07/06/2018 |+---------------------+------------+------------+------------+

Vous ne pouvez le faire qu’avec CONVERT() car :

• CAST() ne prend pas en charge l’argument style ; et
• PARSE() ne convertit pas une date/heure en une valeur de type chaîne de caractères (elle ne prend pas non plus en charge l’argument style)

Quand utiliser PARSE()

Malgré les différents inconvénients de cette fonction (performances, dépendance à .NET, conversions de types de données limitées), elle présente également quelques avantages, et il existe certains scénarios où elle pourrait être votre seul choix. Par exemple, lorsque vous fournissez une date qui comprend le nom du jour de la semaine, comme le vendredi 20 juillet 2018.

Quand les autres renvoient une erreur

Voici des exemples où PARSE() est la seule fonction des trois qui peut convertir avec succès la valeur sans lancer une erreur.

Dans ces exemples, nous tentons de convertir diverses valeurs de chaîne en un type de données de date. Cependant, les valeurs de chaîne que nous fournissons incluent le nom du jour de la semaine. Cela pose des problèmes pour CAST() et CONVERT(), mais PARSE() n’a aucun problème.

PARSE()

SELECT PARSE('Friday, 20 July 2018' AS date) AS 'Result 1', PARSE('Fri, 20 July 2018' AS date) AS 'Result 2', PARSE('Friday 20 July 2018' AS date) AS 'Result 3';

Résultat:

+------------+------------+------------+| Result 1 | Result 2 | Result 3 ||------------+------------+------------|| 2018-07-20 | 2018-07-20 | 2018-07-20 |+------------+------------+------------+

Donc PARSE() n’a aucun problème avec le format de la date que nous fournissons.

CONVERT()

SELECT CONVERT(date, 'Friday, 20 July 2018') AS 'Result 1', CONVERT(date, 'Fri, 20 July 2018') AS 'Result 2', CONVERT(date, 'Friday 20 July 2018') AS 'Result 3';

Résultat:

Conversion failed when converting date and/or time from character string.

So CONVERT() est incapable de convertir la chaîne de caractères quand elle est dans un tel format.

CAST()

SELECT CAST('Friday, 20 July 2018' AS date) AS 'Result 1', CAST('Fri, 20 July 2018' AS date)AS 'Result 2', CAST('Friday 20 July 2018' AS date) AS 'Result 3';

Résultat:

Conversion failed when converting date and/or time from character string.

Et CAST() renvoie la même erreur.

Donc si vous vous retrouvez à obtenir des erreurs avec les deux autres fonctions, essayez PARSE() à la place.

Spécifier la culture

Un autre scénario où vous pourriez préférer utiliser la fonction PARSE() est lors de la spécification de la culture/langue dans laquelle la chaîne est fournie. PARSE() possède un argument facultatif qui vous permet de spécifier la culture à utiliser. S’il est omis, la langue de la session actuelle est utilisée.

Exemple d’inclusion de l’argument culture:

SELECT PARSE('07/01/2018' AS date USING 'en-US') AS 'Result 1', PARSE('07/01/2018' AS date USING 'de-DE') AS 'Result 2';

Résultat:

+------------+------------+| Result 1 | Result 2 ||------------+------------|| 2018-07-01 | 2018-01-07 |+------------+------------+

Une alternative de culture

Malgré l’avantage de pouvoir spécifier la culture avec PARSE(), vous avez la possibilité de modifier les paramètres de langue, ce qui signifie que vous pourriez obtenir le même effet en utilisant CAST() ou CONVERT().

Par exemple, l’utilisation de SET LANGUAGE us_english avant la requête changera les paramètres de langue actuels en us_english. Bien que cela ne vous permette pas de spécifier différentes cultures dans la requête (comme dans l’exemple ci-dessus), cela affecte l’ensemble de la requête (et toute requête ultérieure).

Vous pouvez également modifier les paramètres de format de date de la même manière. Par exemple, SET DATEFORMAT mdy.

Voici un exemple de modification du paramètre de langue avant d’exécuter une requête avec CAST() et CONVERT():

Allemand:

SET LANGUAGE German;SELECT CONVERT(date, '07/01/2018') AS 'Convert';SELECT CAST('07/01/2018' AS date) AS 'Cast';

Résultat :

+------------+| Convert ||------------|| 2018-01-07 |+------------+Die Spracheneinstellung wurde in Deutsch geändert.+------------+| Cast ||------------|| 2018-01-07 |+------------+

us_english:

SET LANGUAGE us_english;SELECT CONVERT(date, '07/01/2018') AS 'Convert';SELECT CAST('07/01/2018' AS date) AS 'Cast';

Résultat:

+------------+| Convert ||------------|| 2018-07-01 |+------------+Changed language setting to us_english.+------------+| Cast ||------------|| 2018-07-01 |+------------+

Rappellez-vous, lorsque vous faites cela, vous changez l’environnement de langue/format de date pour la session. N’oubliez pas de le changer à nouveau !