J'aimerais récupérer le numéro_auto de la clef primaire généré après un
enregistrement.
J'utilise une base de données Mysql, j'ai essayé les méthodes
getGeneratedKeys(), mais sans succés.
Oui, attention d'ailleurs, le rs.next() doit être testé en réalité car il renvoie un booléen indiquant si la ligne sur laquelle il se positionne est valide ou non. Tu risques l'exception si tu ne le testes pas...
donc
if (rs.next() == true) { rs.getInt(1); }
Dans mon code je l'avais omis car en fait, un insert, si jamais il ne fonctionne pas, une exception sera interceptée (par le catch obligatoire) et donc le reste de l'opération ne sera pas fait. En revanche, si l'insertion fonctionne correctement, il y aura forcément une ligne valide dans le recorset donc le rs.next() doit renvoyer 'true' obligatoirement et donc il me semble inutile de le tester dans ce cas précis.
"Julien Arlandis" a écrit dans le message de news:401e8648$0$11233$
Bon je pense que tu auras vu ma réponse (qui fonctionne) dans l'autre branche de ce thread mais je réponds ici à ta question concernant le ResultSet retourné. Ben en fait, c'est comme ça que c'est géré, c'est tout.
Donc, effectivement tu traite le retour de la méthode comme si tu avais fait
un SELECT. Un ResultSet est un objet comme un autre, si une méthode te dit
qu'elle renvoie ça, hé bien tu fais avec ;).
Au passage, dans le même ordre d'idée, si tu te demandes comment faire pour
obtenir le résultat d'une requête du style "SELECT COUNT(*) FROM matable"
(puisqu'on ne spécifie pas de nom de colonne), la réponse est que la valeur
est récupérée avec un rs.getInt(1) après un rs.next()
Ca t'éclaire? :)
Oui, en fait ce qui m'a dérouté c'est l'histoire du rs.next(), quand j'utilisais des recordsets en ASP je crois me souvenir qu'il se plaçait directement sur la première ligne de la requête. Par contre il fallait vérifier qu'on n'était pas à la fin du recordset avant d'appeller rs.Getbidule.
Adobex
Oui, attention d'ailleurs, le rs.next() doit être testé en réalité car il
renvoie un booléen indiquant si la ligne sur laquelle il se positionne est
valide ou non. Tu risques l'exception si tu ne le testes pas...
donc
if (rs.next() == true)
{
rs.getInt(1);
}
Dans mon code je l'avais omis car en fait, un insert, si jamais il ne
fonctionne pas, une exception sera interceptée (par le catch obligatoire) et
donc le reste de l'opération ne sera pas fait. En revanche, si l'insertion
fonctionne correctement, il y aura forcément une ligne valide dans le
recorset donc le rs.next() doit renvoyer 'true' obligatoirement et donc il
me semble inutile de le tester dans ce cas précis.
"Julien Arlandis" <juliendusud@free.fr> a écrit dans le message de
news:401e8648$0$11233$626a54ce@news.free.fr...
Bon je pense que tu auras vu ma réponse (qui fonctionne) dans l'autre
branche de ce thread mais je réponds ici à ta question concernant le
ResultSet retourné. Ben en fait, c'est comme ça que c'est géré, c'est
tout.
Donc, effectivement tu traite le retour de la méthode comme si tu avais
fait
un SELECT. Un ResultSet est un objet comme un autre, si une méthode te
dit
qu'elle renvoie ça, hé bien tu fais avec ;).
Au passage, dans le même ordre d'idée, si tu te demandes comment faire
pour
obtenir le résultat d'une requête du style "SELECT COUNT(*) FROM
matable"
(puisqu'on ne spécifie pas de nom de colonne), la réponse est que la
valeur
est récupérée avec un rs.getInt(1) après un rs.next()
Ca t'éclaire? :)
Oui, en fait ce qui m'a dérouté c'est l'histoire du rs.next(),
quand j'utilisais des recordsets en ASP je crois me souvenir qu'il se
plaçait directement sur la première ligne de la requête.
Par contre il fallait vérifier qu'on n'était pas à la fin du recordset
avant d'appeller rs.Getbidule.
Oui, attention d'ailleurs, le rs.next() doit être testé en réalité car il renvoie un booléen indiquant si la ligne sur laquelle il se positionne est valide ou non. Tu risques l'exception si tu ne le testes pas...
donc
if (rs.next() == true) { rs.getInt(1); }
Dans mon code je l'avais omis car en fait, un insert, si jamais il ne fonctionne pas, une exception sera interceptée (par le catch obligatoire) et donc le reste de l'opération ne sera pas fait. En revanche, si l'insertion fonctionne correctement, il y aura forcément une ligne valide dans le recorset donc le rs.next() doit renvoyer 'true' obligatoirement et donc il me semble inutile de le tester dans ce cas précis.
"Julien Arlandis" a écrit dans le message de news:401e8648$0$11233$
Bon je pense que tu auras vu ma réponse (qui fonctionne) dans l'autre branche de ce thread mais je réponds ici à ta question concernant le ResultSet retourné. Ben en fait, c'est comme ça que c'est géré, c'est tout.
Donc, effectivement tu traite le retour de la méthode comme si tu avais fait
un SELECT. Un ResultSet est un objet comme un autre, si une méthode te dit
qu'elle renvoie ça, hé bien tu fais avec ;).
Au passage, dans le même ordre d'idée, si tu te demandes comment faire pour
obtenir le résultat d'une requête du style "SELECT COUNT(*) FROM matable"
(puisqu'on ne spécifie pas de nom de colonne), la réponse est que la valeur
est récupérée avec un rs.getInt(1) après un rs.next()
Ca t'éclaire? :)
Oui, en fait ce qui m'a dérouté c'est l'histoire du rs.next(), quand j'utilisais des recordsets en ASP je crois me souvenir qu'il se plaçait directement sur la première ligne de la requête. Par contre il fallait vérifier qu'on n'était pas à la fin du recordset avant d'appeller rs.Getbidule.
