Conversion de INTEGER à DATETIME diffère de VB6

Question

Je regarde un code VB6 hérité (années + ans, avant mon temps) qui exécute une requête contre un SQL 2005 db. Il fournit une restriction de date dans la clause WHERE - où la date est donnée en tant que valeur entière à la suite d'un CLng() à la date dans VB6.

par exemple.

... 
WHERE SomeDateField >= 40064 

40064 est ce que VB6 convertit la date d'aujourd'hui (le 8 septembre) en faisant une CLng() sur elle. Cependant, dans T-SQL cet entier convertit réellement le 10 septembre:

SELECT CAST(40064 AS DATETIME) 

Et les résultats ne sont pas comme prévu. Quelqu'un sait ce qui peut causer cette différence de conversion entre VB et T-SQL?

Je suis assuré que cela a toujours fonctionné sans problème, et évidemment ma suggestion est de faire passer les dates en dates au format ISO standard. Mais, besoin d'essayer de trouver la raison derrière cette divergence qui commence à se produire.

Answer 1

Il semble que datetime VB commence le 30 décembre 1899:

?CDbl(#30/12/1899 03:00:01#) 
0.125011574074074 

alors que datetime SQL commence le 1 juin 1900:

SELECT CAST(0 AS DATETIME) 
1900-01-01 00:00:00.000 

Cela donne différence deux jours qui correspond à vos résultats :).

'VB6 
CDbl(#2009-09-08#) 
40064 

-- SQL: 
SELECT CAST(40064 AS DATETIME) 
2009-09-10 00:00:00.000 

Answer 2

Je pense que cela a quelque chose à voir avec le fait qu'il y avait un 29 février 1900. Je crois que VB6 pense qu'il y en a, mais par exemple, JavaScript n'est pas d'accord. Je ne sais cependant pas comment SQL Server gère cela; Je crois que cela ne compte pas non plus. 29.

Answer 3

Il existe un problème similaire entre Excel et SQL Server décrit dans this thread - J'imagine que c'est la même chose?