Je pense qu'il est plus efficace d'utiliser des calculs datetime natifs que tout ce va-et-vient vers divers formats de chaîne, de date et de nombre.
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));
Résultat :
===================
2011-07-05 00:00:00
En supposant que ces données ne changent pas souvent, il peut être beaucoup plus efficace de stocker la date sous forme de colonne calculée (c'est pourquoi j'ai choisi la date de base de 0
au lieu d'une représentation sous forme de chaîne, ce qui entraînerait des problèmes de déterminisme empêchant la colonne d'être persistante et potentiellement indexée).
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;
Résultats :
JDEDate GregorianDate
======= ===================
111186 2011-07-05 00:00:00
Même si vous n'indexez pas la colonne, elle vous cache toujours le vilain calcul, étant persistant, vous ne payez qu'au moment de l'écriture, car cela ne vous oblige pas à effectuer des opérations fonctionnelles coûteuses au moment de la requête chaque fois que cette colonne est référencée ...