Je cherche à additionner une heure à une date. Mon problème est que cette heure et cette date sont au format String car je dois les insérer dans une requete SQL grâce à une requete du style  
 
query="insert into BASEQ.TEST_EXECUTION  (BASEQ.TEST_EXECUTION.EXE_DATE) values  (TO_DATE('" + startTime + "' , 'MM/DD/YYYY HH24:MI')";  
 
avec startTime ma date à laquelle je dois ajouter une chaine contenant une heure.
 
Je ne sais pas comment faire pour additionner ces 2 formats différents de date      

java.util.Calendar

C'est ce que je suis entrain d'essayer d'utiliser mais j'ai quelques problème pour ensuite intégrer la nouvelle date calculée dans ma requete

PreparedStatement

J'avais commencé à utiliser PreparedStatement mais j'avais trop d'erreur. Du coup j'ai entrer mes dates en format Sting, en faisant un To_DATE dans ma requete. Mais en additionnant mes dates, j'obtiens en fin de traitement un calendar et non plus un String. Il faut donc que j'arrive à retransformer  ce Calendar en string

 
je te conseille de reprendre le PreparedStatement et de corriger les erreurs que tu avais.

Super photo !!!!!
 
Une petite question avec le preparesStatement comment tu fais pour affecter ta date à la variable. Est ce que setDate fonctionne?
Je ne pense pas car il prend en paramètre setDate(int, java.sql.Date) et non un GregorianCalendar ou un Calendar
statement.setDate(1,calendar);

totoz

??????????

sur un calendar tu peux faire un getTime() pour récupérer l'équivalent sous forme de Date

J'ai un message d'erreur "null" et je ne comprend pas d'ou vient le probleme.
Voici une partie de mon code :
 
query="insert into BASEQ.TEST_EXECUTION  (BASEQ.TEST_EXECUTION.EXE_DATE) values  (? ))";    
PreparedStatement statement = connection.prepareStatement(query);
statement.setDate(1,(java.sql.Date) calendar.getTime());

 
getTime() te renvoie un java.util.Date (cf moinsmoins, quel nom de methode mal choisi )
on ne caste pas un java.util.Date en java.sql.Date, ca n'a aucun sens.
 
java.util.Date a une methode getTime() qui te renvoie un long
java.sql.Date a un constructeur qui prend un long.
je te laisse donc deviner comment faire passer le Calendar en Date.

getTime de Calendar renvoie un Date... java.util.Date

oups

Désolé mais la je crois que je suis un peu perdue entre les java.sql.Date, java.util.Date et les calendar???  COmment je peux faire pour passer mon calendar en param.

fais un effort ! avec la javadoc et ce qui t'as été dis tu as tout ce qui faut ... faut mettre un peu du tiens, hein !
 
new java.sql.Date(tonCalendar.getTime().getTime())

benou

je veux bien faire un effort mais en plus de la date j'ai besoin de récupérer l'heure et avec cette méthode je n'ai plus l'heure

dans ce cas c'est pas Date que tu dois utiliser mais TimeStamp. ca fonctionne à peu près pareil ... je te laisse regarder la javadoc.

qu'est-ce que tu racontes toi.
le probleme est probablement du coté de sa base: un objet date est précis à la ms

bha non : (javadoc de java.sql.Date)

Pour ca y a Time et TimeStamp (qui ajoute les nanoseconde). Il me semble que c'est ce dernier qui est le plus utilisé.

ha ouais tiens  
va pour Timestamp alors
 
(pouvaient pas faire prendre un util.Date a la methode setDate nan?)

Je comprend pas (et pourtant j'essaye) pourquoi y'en a qui s'evertue à faire du SQL alors qu'avec des outils de mapping objet/relationnel comme Hibernate ce genre de problème s'évanouie.

- parce qu'ils sont à l'école
- parce qu'ils s'en battent les couilles et font ce que le chef à dit. chef qui, en bon chef qui se respecte, ne connait plus à rien depuis 15 ans

je vois pas le problème de faire du SQL : ca va certainement plus vite à mettre en place dans le cadre de petits projets

quand on ne sait pas de quoi on parle, peut etre.
en clair, t'as tord.

 
Pour chez toi ça va
 
mais  
 
petit projet devriendra grand.
 
Sans compter que les éditeurs de SGBDR ont tous ajouter leur subtilités au SQL qui aurait du rester universel.
 
Avec des outils de mapping Objet/Relationnel la prise en compte d'un SGBD particulier se limite à de la configuration.

peut être ...
je connais pas hibernate, mais j'imagine que le temps de formation à l'outils doit pas être négligeable ...
 
et j'ai tendance à me méfier de ce genre d'outils sur les petits projets ...  
 
Genre si t'as 2 tables en base, je vois pas l'intérêt de passer par ce genre de trucs quoi ... si ce n'est opur des raisons politiques de la boite (qui m'oblige d'ailleur à utiliser un truc équivalent ici)

et tant va la cruche à l'eau qu'à la fin elle se casse

le temps de formation, c'est une fois pour toute, et c'est vraiment super rapide à demarrer. va voir la doc, en 5 minutes, pour 2 objets t'es parti.
et puis tu peux faire de l'objet, et t'arretes de te faire chier avec l'antiquité du sql quoi
t'es gagnant à tout point de vue.

 
et puis d'abord le chien aboie et la caravane passe    
 
Plus sérieusement, même pour deux tables j'irai pas m'emmerder à faire du SQL ne serait-ce que pour la compatibilité avec les SGBD.
 
Maintenant, si ton SGBD est fixe et que tu as deux ridicules transactions à faire, pourquoi pas si t'es un pro du SQL.

et ca gère même des requêtes un peu plus compliqué que de bêtes select insert update ? genre des "select ... where id in(...)", des trucs comme ca ?

 
En gros le mapping c'est une table = une classe et une colonne = un atrribut de la classe avec les get/set
Ca se fait dans des fichier xml de conf
 
En plus fin tu décris les contaraintes entre les tables avec des relations one-to-one, one-to-many, many-to-one, many-to-many. Dans le dernier cas tu donne en plus le nom de la table d'indexation et il gère le reste.
 
Les contraintes sont exprimées dans le code sous la forme de méthodes qui renvoient des List ou des Set suivant la contrainte (one-to-one ne correspond pas à une liste !!!). Si tu le souhaites, tu peux spécifier que tu veux les liens inverses.
 
Tu peux toi-même gérer les clés primaires (simples ou composées) ou bien laisser le soin à Hibernate de le faire. Dans ce cas il choisira la meilleur méthode en fonction du SGBD cible.
 
Ex : Une Commande est associée à un seul Client mais un client peut passer plusieurs Commandes -> Sur la classe Commande tu as un attribut de type Client avec ses get/set et tu pourra avoir la classe Client une méthode getCommandes() qui te renvoi un objet List contenant toutes les commandes du client.
 
Si tu veux ajouter une Commande à un client tu fera qqch comme ça :
 

 
Tout l'aspect connection à la base est géré par hibernate.
Tu peux ou non faire des tansactions.
 
Et surtout le plus cool, si tu changes de SGBD en cours de route t'as pas à te retaper toutes tes requêtes pour voir si elles sont acceptées par le nouveau SGBD.
 
C'est mieux de bosser comme ça

ouais, ben c'est un truc classique quoi ... sauf  que tu dois avoir un max de fichiers de config derrière, des sources à générer, etc ... c'est l'équivalent du truc qu'on a ici, et je persiste à dire que pour des besoin simple ca va plus vite de faire ca en SQL.
 
Mais il est évident que c'est l'outil à utiliser pour des projets de taille moyenne ou importante

un bete IN (3,4,5) ??? bah y'a interet
 
si ça t'amuse tu peux meme cracher du sql direct dedans.
 
seulement des crasses style requetes imbriquées etc les 3/4 du temps pour moi c'est signe d'un design louche
 
 

ZERO sources à generer, et tu peux generer TOUS les fichiers de conf à partir de ton code source. et ton code source c'est DES BETES JAVABEANS.
 
PUTAIN TU VA LA LIRE L'INTRODUCTION EN 5 MINUTES OU MERDE!! (au lieu de ramener tes arguments préhistoriques à la con là)

j'irai voir, oui.
 
et mes arguments à la con il t'emmerdent

j'ai lu ...
 
mouais, bof, a tester. Je suis pas super emballé : y a rien de révolutionnaire. La config a l'air assez simple (c'est un bon point) mais c'est assez troublant de HQL ...  C'est pas trop chiant à la longue ?
 
faudrait que je teste ca dans un vrai projet pour bien me rendre compte ...