ISDATE FOR DATETIME2

Bonjour,

Je me pose des questions à propos de la fonction ISDATE.

Cette fonction retourne 1 si l'expression est une valeur date, time ou datetime valide ; sinon elle retourne 0.

Ma question :
Est ce qu'il existe un équivalent pour prendre en compte les types DATETIME2 , DATE ou DATETIME2OFFSET ?

Regarder ceci :

-->> Plage DATETIME2
-- date : 0001-01-01 à 9999-12-31
-- time : 00:00:00 à 23:59:59.9999999

Test1
--------

IF ISDATE('0001-01-01') = 1
PRINT 'VALID'
ELSE
PRINT 'INVALID'

Résultat Test1 : INVALID

Test2
--------
IF ISDATE('23:59:59.9999999') = 1
PRINT 'VALID'
ELSE
PRINT 'INVALID'

Résultat Test2: INVALID


-----

Avez-vous une idée ?

Est ce que SQL SERVER dispose d'une fonction équivalente à ISDATE qui prend en compte les plages des types : DATE, DATETIME2 ou DATETIME2OFFSET ?

Merci d'avance

cf https://connect.microsoft.com/sql/fe...&wa=wsignin1.0

toujours pas corrigé en denali CTP1...

Citation:

---

Envoyé par dbaffaleuf

cf https://connect.microsoft.com/sql/fe...&wa=wsignin1.0

toujours pas corrigé en denali CTP1...

---

D'abord Bonne année David ;) On est encore au mois de janvier :)

Merci pour l'info à propos de la fonction ISDATE. j'ai du mal à croire à cette négligence (je n'ai pas trouvé un autre mot... ) de la part de MS

Et pourtant MS déconseille l'utilisation du type DATETIME ! :oops: et ne prévoit rien pour valider les données des nouveaux types date/heure !?

La manipulation des données date/heure sont très importantes et très CRITIQUE pour les entreprises... Que MS ne corrige pas ces genres de bugs et poursuit les sorties de nouvelles versions (avec les bugs qui vont avec) me surprend !

Avant de sortir les nièmes versions de SQL SERVER, est ce qu'il n'est pas plus crédible de corriger les bugs relevés par les utilisateurs ?

A+

Bonne année à toi. Je pense que la dev team doit avoir des priorités au niveau des fonctionnalités et des corrections, et que ça ne doit pas être si simple. Il faut savoir être patient...;)

Citation:

---

Envoyé par dbaffaleuf

Bonne année à toi. Je pense que la dev team doit avoir des priorités au niveau des fonctionnalités et des corrections, et que ça ne doit pas être si simple. Il faut savoir être patient...;)

---

C'est justement ces priorités que j'ai du mal à comprendre ...;)

Qu'il n'y a rien à la place de ISDATE pour les nouveaux types date/heure sous SQL SERVER 2008 je peux comprendre.

Qu'on passe à SQL SERVER 2008 SP1 je peux encore comprendre

mais à partir de SP2 je peux dire que la patience à des limites...:D

Et que SQL SERVER 2008 passe à R2, à R2 sp1, ... je suis tenter de dire que ça ressemble à de la négligence (je peux me tromper hein ..)

Et j'entend parler ces derniers temps de "denali", pourquoi toujours cette précipitation pour la sortie de nouvelle version...?

Citation:

---

Envoyé par zinzineti

Et j'entend parler ces derniers temps de "denali", pourquoi toujours cette précipitation pour la sortie de nouvelle version...?

---

C'est comme ça, MS a décidé de réduire le temps de sortie entre 2 releases majeures, ça force les gens à migrer plus vite et adopter plus vite les nouveaux standards. Je peux plaider pour le support qui devait il n'y a pas si longtemps encore régler des pbs en SQL 2000 SP4 (avec le terrible parcours du combattant pour déboguer un sqlservr 2000). Tu sais un sgbd c'est probablement le soft le plus sophistiqué à écrire, donc je ne leur jette pas la pierre. A+

Bonjour,

J'ai écrit cette procédure stockée pour valider les données datetim2

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

CREATE PROCEDURE P_IsDate2(@dateStr NVARCHAR(20), @retour INT OUTPUT) AS BEGIN DECLARE @datetime2 datetime2   BEGIN TRY SELECT @datetime2 = CONVERT(DATETIME2, @dateStr) SELECT @retour = 1 END TRY BEGIN CATCH SELECT @retour = 0 END CATCH END   --Utilisation de la procédure P_IsDate DECLARE @re INT EXEC P_IsDate2 N'0001-01-01',@re OUTPUT IF (SELECT @re) = 1 PRINT 'VALID' ELSE PRINT 'INVALID'   --Résultat : VALID   DECLARE @re INT EXEC P_IsDate2 N'23:59:59.9999999',@re OUTPUT IF (SELECT @re) = 1 PRINT 'VALID' ELSE PRINT 'INVALID'   --Résultat : VALID

---

Par contre il est impossible d'utiliser des TRY ... CATCH dans des UDFs. Cette limitation n'est toujours pas levée jusqu'à ce jour.
Quelqu'un a -t-il une méthode de contournement pour mieux gérer les erreurs dans le UDFs ?

Merci d'avance.