Discussion :

[Népomucène]

Solution apporté : format modifié en varchar, je verrais après s'il les opérations de type ORDER BY sont effectué via l'application ou via la BDD.
Au pire, on interviendra à posteriori

En principe, si dans Access c'était un vrai champ date, cela ne va pas fonctionner car Jdbc ne va pas apprécier d'avoir un champ texte
alors qu'il s'attend à avoir une date.
Et il est bien clair que la recherche sur date ne fonctionne pas avec ce format !!! (sauf s'il est en yyy-mm-dd)
Je pense qu'il faut que tu fasses la conversion avant toute autre chose pour éliminer une des causes du tsunami dont tu parles plus bas.

Je ferai comme cela pour une table qui comporte un champ date avec des dates dd/mm/yyyy :
1) Je crée un nouveau champ de type datetime
2) avec une requête SQL et la fonction de conversion tu rempli le nouveau champ
genre : UPDATE matable SET monnouveauchampdatetime = STR_TO_Date(monchampdate, '%d/%m/%Y')
3) après vérification de la bonne conversion, tu supprimes monchampdate
4) tu renome le champ monnouveauchampdatetime en monchampdate (qui est le nom attendu par l'application)

[Spiicky]

Ok Népomucène, je vais m'y attelé dès que possible !

merci pour ce tips

[Spiicky]

Me revoilà !

Alors, pour information, j'ai installé un server MySQL sur un poste ainsi que WorkBench que je découvre au passage (super outil !)
Sur un autre poste, j'ai mon projet ouvert via NetBeans.

La connexion s'effectue correctement et j'arrive à récupérer des données du server.

Cependant, je recontre un petit soucis, voici la ligne d'erreur fournie par NetBean's :
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
Une idée ?

[Népomucène]

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
Une idée ?

Eh non, pas d'idée si on n'a pas le code !!!
C'est l'en-tête standard d'un message d'erreur sous Java donc ...

Bref, on poste le code et on poste la stacktrace d'erreur

[Spiicky]

mea culpa

Alors voici l'erreur plus précisément :
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at coactivite2.Zone.AffichageZone(Zone.java:179)
Accompagné de la ligne concernée (179)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public static void AffichageZone(JTable table)
    {
        try
        {
            DefaultTableModel modele = (DefaultTableModel) table.getModel();
            Vector<Vector<String>> data = null;
            Connexion.query = "SELECT NomZone, NomInstallation FROM zone, Installation WHERE installation.IdInstallation = zone.IdInstallation GROUP BY NomInstallation, NomZone;";
            Connexion.res = Connexion.stmt.executeQuery(Connexion.query);
            int i = 0;
            Utilitaire.centrerTable(table);
            while(Connexion.res.next())
            {
                modele.addRow(data);
                table.setValueAt(Connexion.res.getString(1),i,0);
                table.setValueAt(Connexion.res.getString(2),i,1);
                i++;
            }
        }
        catch(SQLException ex)
        {
            System.out.println(ex.getMessage());
        }
    }

Je viens de vérifié la validité de la requête dans la BDD directement et cela fonctionne parfaitement.

J'émet un doute sur le mot "Connexion"...

nb : un petit warning pour (je ne sais pas si c'est très important) :
Tue Oct 04 09:40:53 CEST 2016 WARN: Establishing SSL connection without server's identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be established by default if explicit option isn't set. For compliance with existing applications not using SSL the verifyServerCertificate property is set to 'false'. You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for server certificate verification.

[Népomucène]

Connexion est écrit "à la française" avec un "x" donc ce n'est pas l'objet connection de Jdbc
mais une classe ad hoc pour gérer les connexions et les statements ... mais pas forcément bien fait à l'évidence.

Je suppose que Connexion.stmt représente un objet Statement mais qui semble être null.
Il faut vérifier son initialisation.
En plus on est dans une méthode statique qui peut être appelée plusieurs fois
et elle peut elle-même appeler Connexion plusieurs fois sans garantie de bonne fermeture des objets.

C'est pas un cadeau ce qu'on t'a donné là !

Pour l'avertissement MySql, ignore-le pour l'instant ; il y a plus urgent à faire.

[ehsavoie]

C'est clair que cette classe Connexion doit être sujette à une très grande prudence car il faut bien nettoyer derrière soi en JDBC.
Si elle est statique j'espère que tu es sûr de ne pas avoir d'accès concurrentiels sinon tu vas au dela de bugs pénibles.

[Spiicky]

D'accord, si je comprend bien, je dois mettre un point d'arrêt sur le statement afin de vérifié sa valeur ?

[Népomucène]

Oui, en utilisant le débogueur tu devrais voir où ça coince.

[Spiicky]

J'avoues avoir un peu de mal à l'utiliser

J'ai cette instruction dans ma fonction Connexion :

Code :

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

1
2
 
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);

Comment pourrais faire pour suivre l'application accompagnée de la valeur de ses variables depuis le début ?

[Népomucène]

Tu mets un point d'arrêt dessus (on a vu comment faire plus haut je crois)
Et tu lances ton application en débug.

[Spiicky]

Je ne sais pas si c'est ce dont nous avons besoin

[Népomucène]

C'est plutôt dans la classe Connexion qu'il faudrait mettre un point d'arrêt sur :

Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);

[Spiicky]

Il veut que je le renomme, je ne comprend pas car si je le fais, de l'autre coté on ne reconnait plus stmt

[Népomucène]

Ah la daube !

stmt a été déclaré comme variable de classe
et au milieu d'une méthode il est à nouveau déclaré en local ce qui écrabouille la variable de classe !

à la ligne 71 il faut supprimer "Statement" :

Code :

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

      stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);

Méfie-toi de cette classe qui a été laborieusement bricolée
(classe laborieuse classe dangereuse )

[Spiicky]

Ca fonctionne ainsi !!! Mille merci Népomucène, tu gères

Bon, je continue sur notre lancée, je vais essayé de faire planté l'application à travers différents cas d'utilisation

Je reviendrais bientôt !

[Népomucène]

Ce qu'il y a d'incroyable c'est que cela a fonctionné avant ...

[Spiicky]

Ouais

[ehsavoie]

C'est moi où je vois des Vector<Vector<>> ?
Comment t'assures tu de la fermeture correcte des statements ?
Si tu utilises un driver JDBC récent tu n'as plus besoin du Class.forName car il est chargé par le ServiceLoader (cf. http://docs.oracle.com/javase/tutori...onnecting.html)

[Népomucène]

Si tu utilises un driver JDBC récent tu n'as plus besoin du Class.forName car il est chargé par le ServiceLoader (cf. http://docs.oracle.com/javase/tutori...onnecting.html)

Cela ne marche pas à tous les coups.
J'ai eu des problèmes de ClassNotFound même avec le dernier driver de Sql Server.
La faute à une bibliothèque une peu ancienne de JasperReport.

Pour l'instant, il faut que Spiicky s'occupe de régler ses problèmes de bons gros bugs qu'on lui a gentiment laissé.
Il est probable qu'il devra s'attaquer à la suppression des méthodes statiques qui, quand elles sont mal programmées, font des plantages difficiles à identifier.
Après, il sera toujours temps de faire un code plus élégant / optimisé (genre supprimer les vectors)