Je debute en java et je souhaite simplement remplir un tableau avec le résultat d'une requete SQL. J'utilise le code suivant
 

 
mais à l'execution j'ai toujours une exception java.lang.ArrayIndexOutOfBoundsException:  
 
Ma façon de remplir le tableau est elle mauvaise ?

Si tu définis un tableau à 2 éléments, les éléments accessibles sont les éléments 0 et 1, pas 1 et 2

en mettant  
les indices 0 et 1 voila ce que j'obtiens    
 
java.lang.ArrayIndexOutOfBoundsException: 0

Pareil pour i : i doit démarrer à 0, pas à 1 ...

oui, j'avais changé les deux   donc je vois pas pourquoi ca marche pas

Affiche rset.getFetchSize() pour voir et dis-m'en des nouvelles.

oui mon fetchsize est à zéro ... pourtant quand je tape ma requete SQL ds la console mysql j'obtiens bien plusieurs résultats... je cherche de ce coté la et je rajoute ds mon code une condition sur fecth <> 0  

Explique quand même l'interêt de mettre un resultset dans un tableau, à mon avis tu fais ça pour rien (sauf si c'est pour  l'amour de l'art )

oui j'imagine qu'il doit y avoir un moyen plus propre et plus rapide donc mon but : afficher le résultat de ma requete dans une Jtable.
 
D'après ce que j'ai compris de la Javadoc je fais un AbstractTableModel avant de créer ma Jtable et mon AbstractTableModel contient un tableau à deux dimensions contenant le résultat de la requete.  
 
J'ai tout faux ?   (Avec des valeurs statique saisie en dur dans le code à la place de la requete SQL ca fonctionne)

1°- Comme le dit Glod, tu ne t'y prends probablement pas bien;
2°- Tu n'utilises de toute façon pas la bonne méthode : lis la javadoc sur setFetchSize et getFetchSize;
3°- et en plus, le driver est manifestement buggé.
 
Quel DBMS, quel driver ?

mysql-connector-java-3.1.6-bin.jar pour mon driver vers Mysql et ds mon code :

 
Avec ce test sur le rset.getFetchSize() j'ai bien sure plus aucune erreur mais ma table est désespérement vide

et tu sais ce que c'est getFetchSize() au moins?
tu esperes recuperer quoi là ?

je veux recuperer le nombre de resultat de ma requete pour déclarer un tableau de la même taille.

et tu sais ce que c'est getFetchSize() au moins? §§T4AS LU LA JAVADOC OU T4AS PRIS LA PREMIERE METHODE QUI ES TOMB2E SOUS L4AUTOCOMPLETION DE TON PUTAIN D4EDITEUR SANS TE DEMANDER SI C4ETAIT LA BONNE§§§???

et oh faut se calmer un peu la monsieur ! Je fais ce que je peux en parcourant la Javadoc. Bon de toute façon c'est le week end donc je verrai ca lundi. Merci à ceux qui m'ont aidé

mon cul.

La javadoc étant en anglais, on peut se tromper...

Sur le nainternet, Gougueule semble dire que getFetchSize() du draïver Maïessecuelle est buggé.
 
Et je ne sais pas comment tu as lu la javadoc, mais il paraît assez clair que ce n'est pas la bonne méthode.
 

My ass.

Sur l'interface ResultSet on ne dispose pas d'une methode permettant
de nous retourner le nombre d'enregistrements de celui-ci.
Il faut parcourir l'ensemble du ResultSet pour connaitre sa taille.
 
Par défaut un ResultSet obtenu par un connection.createStatement() est de type TYPE_FORWARD_ONLY et les méthodes comme last() et first() ne sont pas utilisables sur ce type de ResultSet.  
Regarde les autres méthodes createStatement de Connection et leurs paramètres pour obtenir des ResultSet avec d'autres fonctionnalités.

Plutôt que de parcourir l'ensemble des rows, faire un
rs.last();
puis
int nbRow = rs.getRow();
nbRow contiendra le nombre d'enregistrements.
Y a 2 méthodes, soit on ouvre le statement en scroll insensitive et après ces 2 lignes on fait
rs.beforeFirst();
pour retourner au début et faire le traitement prévu.
Soit on ouvre le statement sans paramètre, on récupère le nombre de row en faisant la requète concernée avec un select allegé (qui ne renvoie qu'une colonne mais donc le where est le même), puis on close le resultset pour le réouvrir avec la requète complète.
 
A vous de faire les tests de perf, la 1ere méthode perd un peu de perf à cause du resultset scroll insensitive, la 2eme n'a pas ce blem mais oblige à faire 2 requètes (dont une très light)
A priori une requete à jointure complexe tournera mieux avec la 1ere méthode, une requète "light" avec la 2eme

et faire tout simplement 2 requêtes? une avec un count() et l'autre avec les champs dont on a besoin
 
Pour l'anglais, c'est un débutant, s'il faut, il a pas l'habitude lire de l'anglais informatique
 
mais c'est vrai qu'on voit tout de suite que getFetchSize, c'est pas ça

En général (je dis bien en général), le count est moins perf, mais ça peut être une solution alternative à ma 2eme solution qui est aussi de faire 2 requètes.

oui enfin bon, suffit d'utiliser une Collection au lieu d'une array hein...

+1, plutôt que de commencer avec des artifices inélégants genre COUNT ou de jouer des curseurs comme un DJ.
 
Note pour le COUNT : pour peu que l'accès DB soit lent, ça ne fera qu'aggraver les choses.

Oui enfin là c'était plus généralement pour compter le nb d'enregistrements d'un rs...

après vision de vos messages, je vois que certains sont toujours énervé pour je ne sais quelle raison    
Je n'ai donc pas utilisé la bonne méthode mais alors deux petites questions svp :  
 
1: getfecthsize dans la javadoc :  
"Retrieves the fetch size for this ResultSet object" donc ca renvoie quoi ?
 
2: comment je fais dans la théorie (je veux pas tout le code juste le principe) pour afficher le résultat d'une requete select dans un Jtable ?   Puisque la méthode que j'utilise ne semble pas la bonne, trop lente et trop lourde (mais je m'en doutais quand même   )
 
Merci de m'aider un peu  

 
1: Ca renvoie la taille (en ligne?) d'un fetch (une récupération de données). Je l'ai rarement vu (sous Oracle) valoriser à autre chose que 0.
Le fetch, c'est la récupération des données (un tuple, une ligne de données) lors de la lecture d'une requête via un curseur (PL/SQL par exemple). Le fetch, c'est un peu le next() du resultset (le resultset étant le curseur).
 
NB pour les puristes: J'ai simplifié pour tenter de pas trop le perdre (c'est un débutant)

en fait c'est plus simple que ca.
 
Quand tu fais obtiens un resultset, tu n'as aucune donnée dedans. Quand tu fait un next(), il va rapatrier autant de lignes que ce qui est défini la dedans.
 
Au prochain next, il utilise une des lignes déjà rappatriées, jusqu'a ce qu'un next() nécéssite des données qui ne sont pas encore récupérées. On a alors un nouveau fetch.

Excellente explication

 
Donc par defaut il rappatrie ligne par ligne et si par exemple je met le fetch size à 2 il en rappatrie deux d'un coup et donc il fait le fetch que sur un next() sur deux ?  
 
Le résuletSet est la vision d'une ligne du résultat que l'on peut déplacer . Il recupère les données nécessaires quand on fait un next() par exemple, mais il les récupère ou ? La résultat de la requête est stockée dans un objet ?

Le résultat de ton next est stocké dans ton resultset, après un next, tu fais un getField(int) (de 1 à xxx) ou getField("nom_champ" )...

Oui, j'ai compris que la méthode d'execution de la requete me renvoie un resultset qui permet d'acceder aux données via next() et getfields ... Mais quand on fait un next() les données sont "chargées" dans le resultset (accessible ensuite via getField("nom_champ" )) mais elles sont chargées d'où ?
 
 
       executeQuery()
BDDSQL ----------------> !----------!----------!
                         !   Nom    !  Prenom  !
                         !----------!----------!  
                         !  Martin  !  Jacques ! <- resultset.next()
                         !  Durand  !  Paul    !
                         !----------!----------!
 
En gros, le tableau est stockée dans le resulset ou dans un autre objet accessible via le resultset ?
 
edit: pourquoi mon tableau est plus aligné après avoir posté le message alors qu'il est tout beau quand je l'édite ?  

Pour le stockage, ça dépend du driver (le truc que tu appelles avec forName("driver.nom.xxxx" ))...
 
En Java, les classes SQL sont des interfaces, c'est à dire qu'elles définissent un "squelette" que chaque développeur de driver devra utiliser pour être JDBC Compliant. Les méthodes ont une description générale de ce qu'elles doivent renvoyer comme résultat. ce qui fait que selon la base et le "fabricant" de ton driver, la façon de procéder est différente.

 
ok ce coup ci c'est bon j'ai tout compris !    Merci !