Eu acho que é mais eficiente usar a matemática de data e hora nativa do que toda essa alternância para vários formatos de string, data e numérico.
DECLARE @julian VARCHAR(6) = '111186';
SELECT DATEADD(YEAR,
100*CONVERT(INT, LEFT(@julian,1))
+10*CONVERT(INT, SUBSTRING(@julian, 2,1))
+CONVERT(INT, SUBSTRING(@julian,3,1)),
DATEADD(DAY, CONVERT(INT,SUBSTRING(@julian, 4, 3))-1,
0));
Resultado:
===================
2011-07-05 00:00:00
Supondo que esses dados não sejam alterados com frequência, pode ser muito mais eficiente armazenar a data como uma coluna computada (é por isso que escolhi a data base de
0 em vez de alguma representação de string, o que causaria problemas de determinismo impedindo que a coluna fosse persistida e potencialmente indexada). CREATE TABLE dbo.JDEDates
(
JDEDate VARCHAR(6),
GregorianDate AS CONVERT(SMALLDATETIME,
DATEADD(YEAR,
100*CONVERT(INT, LEFT(RIGHT('0'+JDEDate,6),1))
+10*CONVERT(INT, SUBSTRING(RIGHT('0'+JDEDate,6), 2,1))
+CONVERT(INT, SUBSTRING(RIGHT('0'+JDEDate,6),3,1)),
DATEADD(DAY, CONVERT(INT, RIGHT(JDEDate, 3))-1,
0))
) PERSISTED
);
INSERT dbo.JDEDates(JDEDate) SELECT '111186';
SELECT JDEDate, GregorianDate FROM dbo.JDEDates;
Resultados:
JDEDate GregorianDate
======= ===================
111186 2011-07-05 00:00:00
Mesmo que você não indexe a coluna, ele ainda esconde o cálculo feio de você, persistindo você só paga isso no momento da gravação, pois não faz com que você execute operações funcionais caras no momento da consulta sempre que essa coluna for referenciada ...
