Des ResultSets défilables

suite,
jusqu’à  ce que la dernière ligne du ResultSet soit traitée. (Le processus est
comparable à  la notion du curseur SQL. Pour en savoir plus sur les opérations
SQL, voir l’ouvrage SQL Developer’s Guide, NEWS/400.)

Cette méthode est parfaitement acceptable pour la plupart des traitements. Mais
il faut parfois plus de souplesse. On peut, par exemple, vouloir réexaminer certaines
lignes précédentes en fonction de ce que l’on trouve dans le ResultSet, ou bien
savoir si la ligne qu’on recherche se trouve près de la fin d’un grand ResultSet.
Dans de tels cas, on peut sélectionner une ligne particulière en utilisant un
ResultSet  » en avant seulement « , mais cette technique peut être inefficace. JDBC
2.0 apporte de nombreuses améliorations à  la manière d’utiliser un ResultSet.
La première consiste à  fournir un complément, appelé previous, à  la méthode ResultSet.next.
Avec la méthode previous, au lieu d’avancer d’une ligne dans le ResultSet, on
recule d’une ligne.

On peut aussi vouloir aller directement en un point quelconque du ResultSet. On
utilise alors les méthodes relative et absolute. La méthode relative requiert
un paramètre d’entrée de type int et déplace la position du curseur dans le ResultSet
du nombre de lignes correspondant. Par exemple, avec relative (5), on atteint
la même position qu’en appelant cinq fois la méthode next ; avec relative (-4),
on atteint la même position qu’en appelant quatre fois la méthode previous. La
méthode absolute prend aussi int comme entrée, mais absolute positionne le curseur
d’après le début ou la fin du ResultSet. Par exemple, absolute (50) déplace le
curseur de 50 lignes depuis le début du ResultSet, et absolute (-5) le déplace
de cinq lignes depuis la fin du ResultSet.

JDBC 2.0 apporte de nombreuses améliorations à  la manière d’utiliser un
ResultSet

Quand on crée un ResultSet, il est positionné avant la première ligne. Par conséquent,
il faut appeler next avant de pouvoir utiliser une des méthodes getXxx. JDBC 2.0
fournit les méthodes beforeFirst et afterLast pour positionner le curseur respectivement
avant la première ligne et après la dernière dans le ResultSet.
Enfin, JDBC 2.0 offre de nombreuses méthodes pour vérifier l’emplacement du curseur
au lieu de le déplacer réellement. Ces méthodes sont les suivantes : isBeforeFirst,
isAfterLast, isFirst et isLast. Chacune d’elles renvoie une valeur booléenne qui
indique si le curseur est positionné ou non conformément à  la méthode. Pour des
détails complets sur les méthodes de défilement du curseur de la classe ResultSet,
consulter la documentation JDBC API à  l’adresse www.javasoft.com. Bien que les
objets ResultSet sous JDBC 2.0 offrent de nombreuses fonctionnalités, on ne peut
par défaut les utiliser afin de préserver la compatibilité avec JDBC 1.1. Pour
utiliser un ResultSet défilable dans JDBC 2.0, il faut que l’instruction créant
les objets de ResultSet soit écrite comme le montre l’exemple suivant qui utilise
le driver JDBC natif :

Statement statement =
connection.createStatement(
ResultSet. TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);

ResultSet rs = statement.executeQuery(
« SELECT * FROM TABLEX »);
// rs is a scrollable ResultSet object

Il s’agit ici d’une nouvelle méthode createStatement qui demande deux paramètres
int. Il y a de nouvelles constantes définies dans la classe ResultSet qui représentent
les diverses valeurs valides pouvant être transmises pour ces paramètres int.
Nous utilisons deux de ces nouvelles constantes dans cet exemple. Le premier paramètre
int indique si le ResultSet est défilable, et le second s’il est actualisable
(nous verrons plus loin comment indiquer qu’un ResultSet est actualisable). Le
tableau de la figure 1 contient une liste complète d’options pour ces paramètres
et leur signification.

Si l’on utilise createStatement et si l’on transmet des paramètres comme TYPE_FORWARD_ONLY
et CONCUR_READ_ONLY, l’instruction renvoyée fonctionnera exactement comme une
instruction JDBC 1.0. On peut bien entendu continuer à  utiliser la version de
createStatement qui ne prend pas de paramètres, et le comportement sera donc identique.
Plus précisément, on ne pourra pas appeler les fonctions de défilement du curseur
ou émettre des mises à  jour par l’intermédiaire du ResultSet.

Voyons maintenant le petit exemple de programme de la figure 2. Notons que le
programme crée un objet ResultSet puis se déplace autour du ResultSet en utilisant
plusieurs nouvelles méthodes. Cependant, la manière dont un ResultSet défilable
fonctionne aujourd’hui pose un petit problème. Une nouvelle méthode appelée getRow
renvoie le numéro de ligne courant dans le ResultSet. C’est satisfaisant tant
qu’on ne commence pas à  effectuer des opérations en se basant sur la fin du ResultSet.
Comme la base de données AS/400 n’a aucun moyen d’indiquer au driver JDBC la ligne
du ResultSet sur laquelle elle se trouve actuellement, les drivers JDBC appliquent
la méthode getRow. Tant que les changements de position du curseur s’effectuent
à  partir du début du ResultSet ou sur la position courante du curseur, le driver
JDBC peut déterminer le numéro de ligne. Mais si on va à  la fin du ResultSet et
qu’on commence à  se déplacer, le driver JDBC, comme la base de données, ne pourra
ni déterminer le nombre de lignes avant la position courante ni le début du ResultSet.

JDBC 2.0 offre de nombreuses méthodes pour vérifier l’emplacement du curseur
au lieu de le déplacer réellement