Database.Guide

Talvez você tenha encontrado as funções T-SQL PARSE(), CAST(), e CONVERT() ao trabalhar com o SQL Server e tenha se perguntado qual é a diferença. Todas as três funções parecem fazer a mesma coisa, mas há diferenças sutis entre elas.

Neste artigo eu pretendo esboçar as principais diferenças entre estas funções.

Comparação

Aqui está uma tabela que esboça as principais diferenças entre as funções CONVERT(), CAST(), e PARSE() no SQL Server:

>

	CONVERT()	CAST()	PARSE()
Definição Oficial	Converte uma expressão de um tipo de dado para outro.	Converte uma expressão de um tipo de dado para outro.	Retorna o resultado de uma expressão, traduzido para o tipo de dado solicitado no SQL Server.
Valor Aceito	Todas as expressões válidas.	Ainda expressão válida.	String.
Valor de retorno	2º argumento, traduzido para o tipo de dados requisitados, conforme fornecido pelo 1º argumento.	1º argumento, traduzido para o tipo de dados solicitado, conforme fornecido pelo 2º argumento.	1º argumento, traduzido para o tipo de dados solicitado, conforme fornecido pelo 2º argumento.
Conversões Suportadas	Entre quaisquer dois tipos de dados.	Entre quaisquer dois tipos de dados.	De string a data/hora e apenas tipos de números.
Concebe o estilo Argumento?	Sim.	Não.	Não.
Concebe a cultura Argumento?	Não.	Não.	Sim.
Requer .NET Framework?	No.	No.	No.	Sim.

alguns outros pontos para além da tabela acima:

• A documentação da Microsoft indica que PARSE() não será removido (uma vez que depende da presença do CLR). Remotar uma função que requer a CLR causaria um erro no servidor remoto.
• Existem alguns valores que PARSE() podem lidar mas CAST() e CONVERT() não podem (por exemplo, strings usando certos formatos de data).
• CAST() está incluído no padrão ANSI SQL-92.
• alguns argumentam que CAST() tem melhor desempenho que os outros dois.
• Existe uma certa sobrecarga de desempenho quando se analisam os valores das strings. Portanto, PARSE() normalmente funcionará mais lentamente que os outros dois.

Below são exemplos de situações onde cada função seria a mais adequada.

Quando usar CAST()

Um bom argumento poderia ser feito para usar CAST() para qualquer cenário que não esteja listado abaixo. Como mencionado, CAST() tem sido parte do padrão ANSI SQL desde SQL-92, portanto deve ser mais portátil entre diferentes SGBD (se isso for um requisito).

Também, alguns argumentam que CAST() tem melhor desempenho que as outras duas (aqui está um artigo interessante que compara o desempenho entre as três funções).

No entanto, existem também razões válidas para que você prefira (ou precise) usar CONVERT() em vez de CAST().

Quando usar CONVERT()

A função CONVERT() pode ser útil quando você precisa usar o argumento style para especificar como a data deve ser formatada ao converter entre uma data e uma string. Aqui estão alguns exemplos:

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';

Resultado:

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

Você só pode fazer isso com CONVERT() porque:

• CAST() não suporta o argumento style; e
• PARSE() não converte de uma data/hora para um valor string (também não suporta o argumento style)

Quando usar PARSE()

Embora as várias desvantagens desta função (desempenho, dependência de .NET, conversões limitadas de tipos de dados), também tem algumas vantagens, e há alguns cenários onde poderia ser sua única escolha. Por exemplo, ao fornecer uma data que inclui o nome do dia da semana, como sexta-feira, 20 de julho de 2018.

Quando os outros retornam um erro

Aqui estão exemplos onde PARSE() é a única função dos três que pode converter com sucesso o valor sem atirar um erro.

Nesses exemplos, tentamos converter vários valores de string para um tipo de dado de data. No entanto, os valores da string que fornecemos incluem o nome do dia da semana. Isto causa problemas para CAST() e CONVERT(), mas PARSE() não tem problema.

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';

Resultado:

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

Então PARSE() não tem problema com o formato da data que fornecemos.

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';

Resultado:

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

Então CONVERT() é incapaz de converter a string quando ela está em tal formato.

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';

Resultado:

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

E CAST() retorna o mesmo erro.

Então se você se encontrar recebendo erros com as outras duas funções, tente PARSE() em vez disso.

Especificando a Cultura

Outro cenário onde você pode preferir usar a função PARSE() é quando você especifica a cultura/idioma em que a string é fornecida. PARSE() tem um argumento opcional que lhe permite especificar qual cultura usar. Se omitido, o idioma da sessão atual é usado.

Exemplo da inclusão de culture argumento:

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';

Resultado:

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

Uma alternativa de cultura

Embora tenha o benefício de poder especificar a cultura com PARSE(), você tem a habilidade de mudar as configurações de idioma, o que significa que você poderia obter o mesmo efeito quando usar CAST() ou CONVERT().

Por exemplo, usando SET LANGUAGE us_english antes da consulta irá alterar as configurações de idioma atuais para us_english. Embora isto não lhe permita especificar diferentes culturas dentro da consulta (como no exemplo acima), afecta toda a consulta (e quaisquer consultas subsequentes).

Pode também alterar as definições do formato de data da mesma forma. Por exemplo, SET DATEFORMAT mdy.

Há um exemplo de alteração da configuração do idioma antes de executar uma consulta com CAST() e CONVERT():

Alemão:

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

Resultado:

+------------+| 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';

Resultado:

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

Lembrar, quando você faz isso, você está mudando o idioma/data do ambiente de formato da sessão. Não se esqueça de o mudar de volta!