Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Conversion d'un DateTime au format SQL
Bonjour à tous
j'aimerais savoir comment générer une data pour un slqCommand qui soit converti correctement au format SQL quelques soit le format de date de SQL ?
En vous remerciant
Jérôme
PS : en fait je recherche l'équivalent en C# de CONVERT (datetime, " & ddatefin & ", 102) en SQL
J'ai pas tout compris.
En c# pour jouer avec les dates il existe l'objet DateTime.
Ced Je construit une command SQL
Dans cette commande qui est un string j'ai par exemple
Puis je remplace je construits mon object DateTime
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Maintenant je veux remplacer mon texte [DATE] par la date au format du serveur SQL et ce quelque soit le format supporté par SQL Serveur. Donc je fais un
Code : Sélectionner tout - Visualiser dans une fenêtre à part DateTime todayDate = DateTime.Now ;
Donc comment puis je généré une chaine de caractère depuis une date avec un format adapté à ma DB SQL....?
Code : Sélectionner tout - Visualiser dans une fenêtre à part insertSQLCmd = insertSQLCmd.Replace("[DATE]", "<LEBORDELQUEJETROUVEPASQUICORRESPONDANTAAUJOURDHUI>");
Suis je plus clair là ?
todayDate.ToString("ddMMyyyy"); n'est pas ce que je cherche...bien sur.
moi je vous dit d'utiliser des sql parameters
ca vous donnerait "insert into table values (@date , @machaine)
avec new sqlparameter(@date,madate) et pareil pour le string
pour les date ca marche à coup sur, peu importe les parametres du serveur
et pour les chaine de caractère ca evite d'avoir des problèmes avec les apostrophes
et ca evite les blague du genre quand un utilisateur doit saisir un texte et qu'il saisie
'' DELETE * FROM table
qui avec votre technique peut faire des choses inattendues (faille connue)
il y a des tuto sur developpez.com
C'est plus clair maintenant
J'ai pas testé mais peut être que ceci marche :
Enfin bref du coté de DateTimeConverter il devrait y avoir la solution.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Qué bourricot. Et comme disait un de mes instructeurs plongeurs y'a 15 ans de cela "avec un bourricot on ne fait pas un cheval de course...LOL ;-)
Bon je vais tester la solution de CED d'abord et sinon je ferais le bourricot
Merci à vous deux
Et voila j'ai 37 ans et je me sens déja vieux. Je vais changer de métier moi.. Ah non j'oubliais je fais du SAP aussi... Bon alors ca va ... Donc ou en étais je ? AH oui ! Tu sais ce qu'il te dit le mec de son temps ? Il te dit que SAP est leader s'en m'em<bip>er avec les trucs de son temps..non mais
;-)
sans vouloir etre mesquin... il faut comparer ce qui est comparable....
Comment dire que SAP est le meilleur, sans un référenciel commun ?
C'est le meilleur (à ton sens) dans son domaine, mais comment pourrais tu comparer SAP à du developpement .NET
A priori les finalités ne sont pas les memes
Je vais te répondre... SAP est meilleure sur un point. Contrairement à d'autres domaines ou on a l'impression ou tout change vite et ou on subit une certaine pression du genre "faut etre de son temps ou époque" qui en final concerne essentiellement des aspects superficiels.
SAP c'est exactement le contraire. Les choses évoluent trés lentement sur l'essentiel...En résumé un gars pointu sur SAP 4.6 (une vieille version) peut bosser sans difficulté sur la derniere version.
Et pourtant SAP est en fait toujours up-to-date technologiquement. Par exemple, cela fait 4-5 ans que SAP propose une solution AJAX sans l'appeler comme cela mais htmlb et pourtant il s'agit bien de javascript avec du XML asynchrone.
La différence entre SAP et le reste, est que SAP ne met aucune pression technologique, mais se base uniquement sur le métier. C'est les besoins métiers qui font qu'on update.
Tu parlais de différenciel ? La référence commune c'est l'expérience. Ainsi un développeur qui a 10 ans d'expérience sur SAP est trés trés bien rémunéré et à une vraie valeur. Je crains qu'un développeur MS ou Java s'il n'a pas suivi le train de toutes les nouvelles versions, est tout simplement un HAS-BEEN.
Je dis cela parceque je suis vraimment étonné par tout le foin qu'on fait à la sortie de chaque nouvelle version de tel ou tel machin, alors que fondamentalement les choses évoluent lentement...
Pas du tout mesquine ta remarque. Au contraire trés intéressante...
étant passé de vb6 à vb8, il m'a fallu moins d'une semaine pour comprendre les changements (vb6 n'est pas objet du tout) et pas énormément plus pour gérer le truc
vous parlez peut etre de c# sans connaitre tout ce qu'il apporte
je ne connais pas SAP donc je ne vais rien dire dessus, ni que c'est pour les vieux qui aime pas évoluer lol
enfin perso moi j'aime bien l'évolution
niveau données, sql server est quand meme plus pratique qu'un fichier indexé, une procédure stockée écrite en .NET avec toutes les possibilité du langage c'est bien pratique aussi
meme si en bas niveau il n'y a pas toujours de changement, en haut niveau il y a une souplesse d'aportée
En réalité c'est un probleme de niveau d'abstraction.
Prend SAP, ou un RAD style PowerBuilder (pour faire de l'executable pas du net)... quelque soit la version ya pas de vrai changement... (le langage intégré propriétaire est toujours aussi pourri... ca change pas)
ce qui change c'est le code généré. Ainsi les dernieres versions de pb si tu install les extensions .NET génère une appli ou du moins des parties en .NET ou va utiliser des composants .NET deja fait... vive l'interoperabilité.
Cependant ce sont des RAD.
.NET est un framework avec une collection phénomènale de classes... quand tu développe en C#... fondamentallement C# connait peu d'évolutions... le framework si... et c'est normal.
Savoir programmer en .NET ne signifie pas connaitre toutes les classes, moi meme je n'aurais pas la prétention de connaitre toutes les classes car j'en suis très loin, quand j'ai besoin d'une classe spéciale, je cherche comme un grand et si elle existe pas ba je prend mon courage à deux mains et je l'implante.
Un programme compilé en dotnet 1.1 marche très bien sur dotnet3.5... à titre de comparaison.
Dans tous les cas, il faut se tenir au fait des nouvelles technologies, meme si tu utilise un environnement (SAP par exemple) qui te masque ces évolutions.
Je dirais meme que cet aspet, qui te masque les évolutions, est un frein.
Quand à la paye, c'est juste qu'un débutant en SAP sera moins productif sous SAP qu'un expert... assez logique, et puis il y a aussi l'aspet offre/demande qui entre en jeu... il y a beaucoup plus de demande que de développeur SAP en réalité... ce qui impacte sur les salaires, tout simplement.
Prend une société comme une société concurrente à la mienne qui fait tous ses applicatifs en powerbuilder... les développeurs PB expérimentés ne sont pas légions, bien au contraire... cette société n'a pas le choix... elle doit donc accepter de les payer prix d'or meme s'ils ne valent pas grand chose...
D'ailleurs les développeurs PB sont de moins en moins nombreux car on ne sort pas d'école formé a PB, sauf cas particuliers... ou parce que té tombé sur des enseignants fans et qui ne jurent que par ca.
L'évolution de l'informatique est de concevoir toujours et toujours des couches supérieur se basant sur les couches inférieures.
Donc les choses évoluent forcément vite, mais l'utilisation de ses couches est simplifiés à tel point qu'un jour un enfant de 4 ans pourra développer en 30 minutes une application complexes qu'un développeur mettrais 6 mois à faire en assembleur.
Je pense que le futur des développeurs seraient de faire de la conception : c'est à dire de faire l'architecture du programme, spécifié les relations qu'il y a entre ses composants à l'aide d'un contrat d'interface.
(Bien sur il restera une phase de test, mais elle peut être sous traiter à d'autres personnes que le concepteur
On peut imaginer dans un futur pas très lointains, un développeur (renommer concepteur) qui conçois un logiciel en débatant de l'architecture à adopter avec son ordinateur.
Et une fois que l'architecture serait adopter l'ordinateur comme un grand rechercherais sur le réseau sur lequel il se trouve les composants nécessaires, créerais ceux qu'il ne trouve pas, et enverrais une demande de création de composant à un technicien pour les composants qu'il n'est pas capable de créer.
L'ordinateur concevrais alors le logiciel, qui ne serait en fait qu'un schéma d'architecture sur lequel est précisé où se trouve les différents composants, et qu'elles sont leur relations.
Lorsque le logiciel serait lancer par un utilisateur, un interpréteur ne ferait que lire ce schéma d'architecture et mettrais en relation les différents composants en respectant le(s) contrat(s) d'interface(s) définie(nt) par ces composants.
Tout cela pour dire inutile de s'attacher à un langage de programmation, un jour on utilisera des couches supérieurs que l'on ne pourra plus appeler langage de programmation.
Ced comme d'hab j'aime beaucoup ta réponse, mais je ne suis pas du tout d'accord. J'ai remarqué que l'informatique avait tendance à convulser... avec des cycles assez lents. Je pense que la tendance multicouches va atteindre un tel niveau d'enthropie que cela ne sera plus gérable et qu'on fera le chemin inverse.
Ce que regrette surtout c'est que ce côté multicouche à tendance à nous faire perdre d'autres voies de vue.
J'ai la chance d'etre le chef d'un projet de 700 jours sur lequel j'ai eu carte blanche. J'ai pus ainsi mettre en place un environnement collaboratif et avoir une approche similaire à XP pour la gestion de projet, qui s'inspire en fait d'une gestion de projet pratiqué par un industriel dans les années 50. techniquement je m'appuie sur DotNetNuke pour le frontend, mais aprés avoir évalué une approche SOA, j'ai finalement basculé vers une approche de réseau d'agents (dans le passé j'ai été le fondateur d'une PME spécialisé dans la cybernétique, rien a voir avec les ERP mais bon) et viré l'approche SOA. Si j'utilise une classe technique chaque module est sans dépendance avec d'autres modules... En gros je m'éclate avec du inhabituel mais qui marche... (pour l'instant)...
Ce que je veux dire c'est qu'il est important qu'on reprennes la main sur la partie créative du dév et qu'on ne deviennes pas des assembleurs de composants, c'est une fausse bonne solution.
Pour revenir à SAP... Bah SAP en étant trés stable nous offre énormément de liberté... paradoxal non
Cela se tient et l'avenir nous diras qui a raison.
Mais bon en même temps actuellement la philosophie de la société actuelle c'est : "Toujours plus rentable" donc toujours plus de fric pour les actionnaires.
Ne dit on pas : "Le temps c'est de l'argent". Donc tout ce qui amène un gain de temps est très apprécié aujourd'hui.
C'est une des raisons pour lesquelles on automatise tout aujourd'hui (la deuxième raison est la diminution du personnel
Donc je ne vois pas pourquoi cela s'arrêtrais.
En même le temps le jour où l'on connectera un "esprit" humain sur un réseau informatique, cela changera tellement de chose que tout pourra arriver
je rajouterais autre chose qui a pas forcément à voir avec les langages mais plutot leur choix
j'ai fini les études récemment, je n'ai pas entendu parler de SAP (à tord peut etre nous dirait jerome ^_^)
donc j'imagine que pour développer sur ce support il ne faut habiter la campagne ...
le choix d'un langage courant permet de trouver plus facilement un poste (meme s'il sera moins payé dans les boites qui s'en foutent du turn over)
et n'oublions que microsoft aime bien avoir le monopole
C'est vrai que SAP est un truc d'initié, mais il est tout à fait possible d'acquérir un minisap pour une trentaine d'euro (via google tu trouveras tout ce qu'il faut savoir sur le sujet).
La vraie question est pourquoi les écoles d'informatique ne forment pas à SAP qui est le 4°eme éditeur de logiciel et le n°1 dans les ERP....
Répondre avec citation
Partager