Re: Transaction en erreur sur CLOSE ou INSERT

On 10-01-2009, philippe(dot)beaudoin(at)bull(dot)net wrote:
> Bonjour à tous, et que cette nouvelle année vous soit douce...
>
> La migration vers PostgreSQL d'une très grosse application sur laquelle
> j'assiste un client me pose 2 problèmes qui ne sont pas sans rapport.
>
> 1) CLOSE curseurs préventifs
>
> L 'application, très modulaire, concentre les accès aux données dans des
> programme C qui utilisent de nombreux curseurs. Pour certains d'entre eux,
> il y a un CLOSE curseur codé avant l'OPEN, afin de s'assurer que le curseur
> est bien fermé (il n'est pas toujours aisé de savoir si un autre programme
> aurait ou non effectué un COMMIT).
> Avec les SGBD actuellement utilisés par ce client (DB2 sur Z-OS et RFM-II
> sur GCOS 8), si le curseur n'est pas ouvert, le CLOSE retourne un SQLCODE
> particulier mais l'application peut se poursuivre par l'OPEN du curseur
> puis les FETCH pour récupérer les lignes. (en revanche, un OPEN d'un
> curseur déjà ouvert provoque une erreur « grave » qui aborte la
> transaction)
> Avec PostgreSQL, le CLOSE d'un curseur non ouvert retourne aussi un statut
> d'erreur, mais la transaction en cours ne peut se poursuivre par l'OPEN du
> curseur sans un rollback, mettant ainsi à mal toutes les éventuelles mises
> à jour effectuées auparavant !
>
> D'où les questions :
> - Existe-t'il une solution avec PostgreSQL permettant de considérer le
> CLOSE d'un curseur non ouvert comme « pas grave », c'est à dire ne mettant
> pas en péril la transaction courante ?

Dans ce cas j'utiliserai une couche d'abstraction, comme le font les
pools de connexions avec les connexions. Ainsi tu gère les closes et
opens au même endroit...

--
William Dodé - http://flibuste.net
Informaticien Indépendant