Discussion :

[Seth77]

Salut

y a t il une fonction, permettant de convertir une date de type DateTime en format valide pour une requete SQL ?

thx

[LaChips]

Bonjour,
En fait le format de ta date est différent pour chaque base de données (à peu de chose prêt) donc précise la base de données

[Seth77]

Ah oui ....

Base de donnees Access ....

Est ce que le format dependra egalement de la localisation ?

[X-Nem]

quand je fais un insert ou un update, avec un sqldatasource
avec ma date ca marche direct

[X-Nem]

Ah oui ....

Base de donnees Access ....

Est ce que le format dependra egalement de la localisation ?

ca faut voir sur ta base access le format

[bilb0t]

En utilisant les paramètres c'est le framework qua ve te convertir tout ça très bien.

Maintenant si tu fait des requetes sans paramètres c'est que tu codes comme un porc et là on peut rien faire.

[SesechXP]

Salut !

Je travaille avec une base de données SQLite et pour utiliser un DateTime dans une requête SQL je fais :

Code :

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

maDate.ToString("yyyy-MM-dd HH:mm:ss")

Peut-être qu'il faut faire quelque chose de semblable avec Access...

++

[bilb0t]

Mais pourquoi est-ce que les gens continuent à coder comme des porcs ?

Quand j'engage quelqu'un je passe 6 mois à lui apprendre à travailler !!!

une requete sql ça se fait avec des params !!!

http://webman.developpez.com/article.../sqlparameter/

[SaumonAgile]

Mais pourquoi est-ce que les gens continuent à coder comme des porcs ?

Quand j'engage quelqu'un je passe 6 mois à lui apprendre à travailler !!!

une requete sql ça se fait avec des params !!!

http://webman.developpez.com/article.../sqlparameter/

Tu aurais pu être un peu moins brutal, mais force est de reconnaître qu'il y a un fond de vérité dans tes propos, je suis confronté à la même situation au quotidien.

[Seth77]

Kler que c brutal !!
Quel est VERITABLEMENT l interet des parametres pour les requetes SQL ?

[SaumonAgile]

Hmmm l'interêt est énorme.

Premier point s'il est nécessaire de le rappeler, ça évite les problèmes de DateTime. Le IDataParameter est de type DateTime, le champ dans la base est de type DateTime, la valeur qu'on veut lui passer est de type DateTime, ça ne vous a jamais choqué de devoir convertir vos valeurs en string dans vos requêtes (que ce soit un DateTime ou autre chose) ?

Deuxième point : Une fois votre requête écrite avec les paramètres, elle ne change plus quelle que soit la valeur que vous mettrez ensuite dans le paramètre. Clin d'oeil à tous ceux qui concatènent leur requête INSERT dans une boucle.

Troisième point (lié au deuxième) : les SGBD standard mettent en cache les requêtes, une requête paramétrée est enregistrée efficacement et optimisée dans le cache, les requêtes construites en dur polluent le cache.

Quatrième point : Le fait d'utiliser des paramètres SQL vous met définitivement à l'abri des erreurs (trop fréquentes) de "J'ai un apostrophe dans ma chaine, ça fait tout casser ma requête Ouin/Ouin/Please/Up/Résolu/Boulet".

Cinquième point : vous vous mettez à l'abri des SQL Injections, pour tous ceux d'entre vous qui concatènent directement un TextBox dans leur requête.

Sixième point : En utilisant concaténant vos valeurs dans la requête, vous introduisez une source d'erreur, une couche d'illisibilité supplémentaire.

Septième point : En concaténant la requête, vous passez à côté de toute la belle gestion des erreurs du framework en abandonnant une hypothétique invalidecastexception en débogage au 'profit' d'une espèce d'erreur SQL générique qui ne vous donne aux mieux qu'une appréciation minable de la source de l'erreur.

Voila.

EDIT : Typos

[SesechXP]

Mais pourquoi est-ce que les gens continuent à coder comme des porcs ?

Quand j'engage quelqu'un je passe 6 mois à lui apprendre à travailler !!!

une requete sql ça se fait avec des params !!!

http://webman.developpez.com/article.../sqlparameter/

Sans doute parce que "les gens" apprennent à développer.

Dans mon cas ça ne fait que quelques mois que j'apprends la POO, le .Net 2 et le SQL en parallèle. J'en apprends tous les jours, de nouvelles choses et aussi de meilleures techniques. Je ne me suis pas encore penché sur les requêtes paramétrées, tout d'abord parce que je n'en avais pas encore vu l'intérêt.

En tout cas merci pour le lien, je vais appliquer ça de suite.

++

[SaumonAgile]

Je passe 15 minutes à écrire une tartine, et personne ne l'a lue
C'est vraiment trop injuste

[SesechXP]

Je passe 15 minutes à écrire une tartine, et personne ne l'a lue
C'est vraiment trop injuste

Non non non ne pleure pas...

J'ai lu ton post, et je suis convaincu de la nécessité des requêtes paramétrées. Comme je l'ai dit juste avant, je vais appliquer tout ça.

++

[X-Nem]

pourquoi est ce que tu ne parse pas ta date
genre datetime.parse qqe chose avant de l'insérer dans la base
non je dis n'importe quoi

[SaumonAgile]

pourquoi est ce que tu ne parse pas ta date
genre datetime.parse qqe chose avant de l'insérer dans la base

Tu sors

[X-Nem]

Tu sors

non je sais je me suis rendu compte
faut l'inserer avec une requete et c qu'en string oui je sais

[bilb0t]

Hmmm l'interêt est énorme.

Premier point s'il est nécessaire de le rappeler, ça évite les problèmes de DateTime. Le IDataParameter est de type DateTime, le champ dans la base est de type DateTime, la valeur qu'on veut lui passer est de type DateTime, ça ne vous a jamais choqué de devoir convertir vos valeurs en string dans vos requêtes (que ce soit un DateTime ou autre chose) ?

Deuxième point : Une fois votre requête écrite avec les paramètres, elle ne change plus quelle que soit la valeur que vous mettrez ensuite dans le paramètre. Clin d'oeil à tous ceux qui concatènent leur requête INSERT dans une boucle.

Troisième point (lié au deuxième) : les SGBD standard mettent en cache les requêtes, une requête paramétrée est enregistrée efficacement et optimisée dans le cache, les requêtes construites en dur polluent le cache.

Quatrième point : Le fait d'utiliser des paramètres SQL vous met définitivement à l'abri des erreurs (trop fréquentes) de "J'ai un apostrophe dans ma chaine, ça fait tout casser ma requête Ouin/Ouin/Please/Up/Résolu/Boulet".

Cinquième point : vous vous mettez à l'abri des SQL Injections, pour tous ceux d'entre vous qui concatènent directement un TextBox dans leur requête.

Sixième point : En utilisant concaténant vos valeurs dans la requête, vous introduisez une source d'erreur, une couche d'illisibilité supplémentaire.

Septième point : En concaténant la requête, vous passez à côté de toute la belle gestion des erreurs du framework en abandonnant une hypothétique invalidecastexception en débogage au 'profit' d'une espèce d'erreur SQL générique qui ne vous donne aux mieux qu'une appréciation minable de la source de l'erreur.

Voila.

EDIT : Typos

Waouw, je ne l'aurais pas mieux dit !!!