Comment empêcher le Lock des tables lors de SELECT dans éditeur de scripts SQL d'ACS ?

[mgardes]

Bonjour

Lors d'un SELECT sur des tables (PF ou tables SQL) effectué depuis l'éditeur de scripts SQL d'ACS (dernière version et anciennes également), la table est lockée (wrkobjlck sur la table retourne un lock de QZDASOINIT) et ce lock persiste même parfois quand on lance d'autres requêtes derrière. Le seul moyen certain d'enlever les locks est de couper la connexion via un "CTRL F12".

En faisant la même chose depuis un écran verts via STR SQL ou via IBM Data Studio il n'y a pas de lock.

Quelqu'un connaît il un moyen d'empêcher que ces locks se mettent en place ?

Merci

[nbonnet]

Bonjour,

Quelles sont les valeurs de niveau de contrôle transactionnel entre STRSQL et ACS ?

Cordialement,

[thomas.barberot]

Bonjour.
J'ai le même problème.
Le niveau d'isolement indiqué dans ACS est "Pas de validation (*NC et *NONE)"
Lorsqu'on affiche le contenu d'une table de travail, il est impossible de lancer un traitement qui fait un CLRPFM par exemple, tant qu'on a pas fermé la connexion.

[nbonnet]

Bonjour,

Pour un select, ACS ouvre un curseur pour parcourir les résultats. Seules les 100 premières lignes sont ramenées. Les autres en fonction de la pagination.
Lorsque l'ensemble des lignes est retrouvé, le curseur est fermé et le verrouillage du fichier disparaît.

Par exemple : SELECT ... sur un fichier avec 3 enregistrements ne génère pas de verrouillage persistant.

Vous avez maintenant un bouton dans ACS en bas à droite de la fenêtre des résultats : "Retrieve all rows" qui parcourt l'ensemble du curseur et le ferme.

Si vous voulez forcer la fermeture du curseur sans lire toutes les données :
Menu "Affichage" -> "Fermeture de tous les résultats"

ou exécutez simplement une autre instruction SQL :
select * from sysibm.sysdummy1

Si rien n'y fait : Connexion -> reconnexion (attention aux transactions non validées, changement de schéma par défaut ...)