Quel est l'inconvénient d'un curseur WITH HOLD ?

Un curseur est fermé par COMMIT WORK, sauf si vous le déclarez « WITH HOLD ». Quel est le véritable avantage de ce comportement par défaut ? Y a-t-il un problème si je déclare tous les curseurs « WITH HOLD » afin d'éviter ce comportement par défaut ? Cordialement, Carl Wu

Bonjour Carl, le manuel indique : Si vous utilisez un curseur de défilement avec maintien (scroll cursor with hold) dans une transaction, vous ne pouvez pas forcer la cohérence entre votre table temporaire et la table de la base de données. Un verrou au niveau de la table ou les verrous posés par le mode Repeatable Read sont libérés à la fin de la transaction, alors que le curseur de défilement avec maintien reste ouvert au-delà de la fin de la transaction. Vous pouvez modifier les lignes libérées dès que la transaction se termine, mais les données extraites dans la table temporaire risquent d'être incohérentes avec les données réelles. Cela m'amène à penser qu'il ne faut pas utiliser cette fonctionnalité par défaut, mais seulement dans des cas particuliers. En espérant que cela aide, Chris Carl Y. Wu a écrit : > Un curseur sera fermé par COMMIT WORK sauf si vous le déclarez « WITH HOLD ». > Quel est le véritable avantage de ce comportement par défaut ? > Y a-t-il un problème à déclarer tous les curseurs « WITH HOLD » pour éviter ce > comportement par défaut ? > > Cordialement, > Carl Wu

Je les utilise comme ceci : foreach ... hold cursor begin work; sql, etc commit work; end foreach un problème ? Manel

C'est également ainsi que je les utilise : pour maintenir un curseur sur une table pilote et valider les transactions individuellement. C'est l'un des usages particuliers que Chris a mentionnés. Art S. Kagel « Manel Falcó i Aige » a écrit : > > Je les utilise de cette manière : > > foreach ... hold cursor > > begin work; > > sql, etc > > commit work; > > end foreach > > un problème ? > Manel