Discussion :

[LhIaScZkTer]

Salut à tous,

Dans mon application je gère des dates et pour que le format de la date soit toujours bon, je me suis dis que j'allais faire confiance à FormatException et à DateTime.Parse()

Le problème est que le format de date géré par DateTime.Parse() est bizarre. La date suivante est jugée comme correct : 14.05.008 et ne renvoie donc aucune exception.
Le code C#

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
try
        {
            if (date.Value.Trim().Length != 0)
            {
                DateTime.Parse(date.Value);
            }
        }
        catch (FormatException fe)
        {
            LblSqlErreur.Text = fe.Message;
            boException = true;
        }

Donc je me suis dis, je vais sur SQL-Server juste pour voir si j'ai le droit à cette même bizarrerie tout droit sortie de derrière les fagots :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT CAST('14.05.008' AS  DATETIME) AS date

Evidemment ça ne marchait et j'ai eu le droit à cette belle erreur : La conversion d'un type de données CHAR en type DATETIME a donné une valeur hors limite de date et d'heure.

Voilà comment les étapes se suivent :
Page aspx : qui a un champ de recherche sur la date, si un enregistrement existe dans la base de données correspondant au critère saisi celui-ci est affiché.

Codebehind : bloc try - catch englobant une condition qui teste que la date ne soit pas vide. On parse la date à l'aide de DateTime.Parse(), si une exception est levée on affiche le message d'erreur et on met la variable boException à true. Après le bloc try - catch une condition qui teste si boException est à true on ne peut pas poursuivre notre recherche, sinon on exécute une méthode nous renvoie une chaine de caractère à affecter au SqlDataSource qui est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SqlSourceRapport.SelectCommand = myCreation.rechercheRapport(DropDownListClient.SelectedValue, DropDownListRapport.SelectedValue, date.Value, etat);

Là, j'ai une SqlException lors du remplissage de mon GridView que je n'arrive pas à récupérer. Evidemment le message d'erreur renvoyé est le même que cité en rouge plus haut.

Quelqu'un aurait-il une idée sur la manière de procéder pour récupérer cette exception ?

Merci pour votre aide.

[tomlev]

Par défaut, dans un programme .NET, le format de date utilisé par DateTime.Parse dépend de la culture du système (ou du thread courant). Mais tu peux très bien spécifier à Parse un format spécifique, prédéfini ou complètement personnalisé.
Sur SQL Server, il me semble que le format utilisé dépend de la variable DATEFORMAT, ou quelque chose comme ça.

Donc, au final, le format de date par défaut dans ton programme et dans SQL Server ne sera pas nécessairement le même, d'où tes problèmes.
La solution est d'utiliser des requêtes paramétrées, comme expliqué ici :
http://johannblais.developpez.com/tu...s-donnees/#LIV
De cette manière, tu n'as plus à te préoccuper du format, car la date est transmise sous une forme insensible à la culture.

Autre petite remarque :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

je me suis dis que j'allais faire confiance à FormatException et à DateTime.Parse()

Evite d'utiliser des exceptions pour faire ce genre de vérification, car ça a un impact non négligeable sur les performances. Les exceptions doivent être réservées à gérer des erreurs imprévisibles qu'on ne peut pas détecter autrement. Pour ce cas précis, utilise TryParse à la place de Parse

[LhIaScZkTer]

Salut tomlev et merci beaucoup pour ton aide

J'ai essayé avec tryparse et ça marche nickel ! Je vais utiliser ça pour la suite.
Par contre, j'ai pas le courage de changer le reste de mon code

Je posterais demain la solution que j'avais trouvé ... un truc très rustique comme je les aime

Pourrais-tu m'en dire plus sur les exceptions et les baisses de performance, je serais très heureux d'en apprendre un peux plus.

Merci beaucoup pour ton aide.

[tomlev]

Je n'ai pas d'explication très précise sur pourquoi c'est mauvais en terme de performance, mais a priori c'est lié au fait que les exceptions remontent la pile jusqu'au premier bloc try/catch rencontré, ce qui est assez couteux

La preuve en chiffres (avec Parse et TryParse justement) :
http://www.codinghorror.com/blog/archives/000358.html

[LhIaScZkTer]

Superbe la réponse merci beaucoup.

Je vais enfin pouvoir dormir tranquille, enfin pour ce soir