ahaa!! moi j'ai fait comme dans la javasoc, j'ai mis le commit dans la méthode insert pas dans l'appel, comme ça serai mieux pour moi, espérons que ça va sauvegarder
Version imprimable
ahaa!! moi j'ai fait comme dans la javasoc, j'ai mis le commit dans la méthode insert pas dans l'appel, comme ça serai mieux pour moi, espérons que ça va sauvegarder
j'ai effacé les catch et modifié le code
mais maintenant même les fonctions du père et mère ne fonctionnent plus et je n'ai aucune exception, vraiment je me désespère avec ce maudit code, s'il me donne une exception au moins je saurais chercherCode:
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
ça, tu n'en seras sûre que quand tu les afficheras : e2.getStackTrace(); n'affiche rien. C'est e2.printStackTrace(); ! Et ça affiche dans la sortie standard d'erreurs (System.err) (donc la console, ou possiblement un fichier si tu as redirigé la sortie standard... tu testes avec quoi ?)Citation:
Envoyé par Hind4Dev
il n'affiche vraiment rien et ce depuis deux jours seulement, avant la console fonctionnait
je teste juste en regardant ma base de données, si les infos sont bien stockées ou pas puisque la console ne fonctionne pas
Mais e2.getStackTrace(); n'affichera jamais rien !
j'ai eu tout ça en console:
Code:
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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Donc, tu as toujours cette erreur que tu avais déjà : la récupération du résultat après l'avoir fermé. C'est quoi le code actuel de insertMere()...(on voit que c'est dans insertMere dans la trace :at brsClasses.TabbedPane.insertMere(TabbedPane.java:337) !)
je croix que je commence à me perdre
Code:
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
Si tu avais fait ce qu'on avait dit : je vois encore stat et rstl déclarés en attributs de classe, le getInt() dans le finally !
Ce qui devrait s'écrire proprement :Code:
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
34
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
j'ai eu une exception pointant sur ça:
c'est la première fois que je travaille avec dateChooser j'ai pris ce code d'une vidéo de tuto
Code:
2
3
Il y a en plusieurs des datechoosers déjà, donc là, je peux pas si c'est la bonne manière de faire ou pas (à part que ça me semble bien tordue comme manière de faire : normalement, on devrait avoir un getDate(), ou quelque chose comme ça).
Mais, le plus important, c'est quoi l'exception ?
pour le date schooser je vais mettre à la place un mask car c'est une date de naissance, le date schooser aide plutot pour les date courante.
voilà l'exception:
Code:
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
34
35
36
37
38
39
40
Oui, un JFormattedTexfField, voire, plus simple pour saisir, un JSpinner avec SpinnerDateModel.Citation:
Envoyé par Hind4Dev
Pour l'exception, il y a une référence null dans la ligne. Pas évident pour moi de savoir laquelle. Soit c'est dateChooser, parce que ce n'est pas la bonne variable que tu utilises. Soit c'est le dateEditor, ou l'UIComponent, pour je ne sais quelle raison attachée au fonctionnement et l'usage du JDateChooser lui-même...
Soit tu utilises le débogueur, soit tu traces (en affichant chaque référence, dans l'ordre de la plus haute, à la plus basse, en mettant des conditions pour pas causer une NullPointerException), ou tu affiche la référence la plus haute, tu testes, tu affiches la suivante, tu testes, et ainsi de suite jusqu'à celle qui est nulle.
Mais si tu changes de composants, c'est encore plus simple. Par contre, si c'est une date ce champ, pourquoi utiliser la méthode setString() ? Tu stockes la date en VARCHAR ? Ce n'est pas forcément une bonne idée, tout dépend ce que tu comptes en faire :
- juste l'afficher, donc c'est pas trop grave, excepté que dans le cas général, il ne faut pas faire ça, ne serait-ce parce qu'on ne peut plus localiser l'affichage ;
- faire des calculs, comparaisons, tris, etc... auquel cas, ce n'est pas bon du tout.
le champ dans ma base est de type date, j'ai mis un champ mask et je l'ai introduit de cette manière
apparamment c'est faut il me dis "java.lang.String cannot be cast to java.sql.Date"Code:
2
la déclaration
Code:
2
3
4
5
6
Bah, oui, c'est normal : Un JFormattedTextField avec un MaskFormatter ne retourne que du String. Tu peux le convertir en java.util.Date avec un SimpleDateFormat.parse(). Il faudrait au moins ajouter un InputVerifier, parce que là on peut saisir 42/42/0000 qui n'est pas une date valide (ça va planter à la conversion).
Il vaut mieux utiliser un JFormattedTextField avec DateFormat :
Attention, c'est un java.util.Date qui est produit, or il te faut un java.sql.Date (voir ici pour la conversion).Code:
2
3
4
5
6
7
8
y'a pas autre méthode plus simple pour sauvegarder une date juste pour tester la sauvegarde dans ma base? je verrai après ce cours de date formatter
Simplement
?Code:stat.setDate(29, new Date());