Discussion :

[o0arthas0o]

Bonjour à tous.

Je travail actuellement sur lock db2 et je viens de rencontrer monb premier problème.

Avec un utilisateur admin, je lock une table avec la commande:
lock table NAME in exclusive mode

Et puis avec un autre utilisateur que je viens de crée appartenant au group db2 Public et ayant les droit de select et update sur la table en question, je test de lire la table puis de mettre à jour une ligne..
Et le problème est que cet utilisateur y arrive, pourtant, mon utilisateur admin avait verrouiller cette dernière...

Le problème est le même en share mode.

J'essaie de trouver la solution pour que mon utilisateur du groupe public reçoit un message d'erreur lui signalant que la table en question est verrouiller.

Je vous remercie d'avance (en espérant que qu'une personne puisse m'aider ^^ )

[alex.]

Bonjour,

Si tu arrives à faire de la maj, c'est que ton lock exclusive n'est plus tenu. Il y a dû y avoir un commit quelquepart. Regardes dans le paramétrage de ton interface si tu n'as pas une option du genre autocommit à ON/YES.

Alex.

[o0arthas0o]

merci, je vais regarder sa de suite.
_____

edit:
apres divers recherche, boulders et autre, j'ai trouvé une seul variable "autocommit" qui se situe dans le fichier db2cli.ini
Celle ci est déja sur 0 (off)
Je vais continuer mes recherches, le temps qu'une personne poste la réponse à cette question qu'elle c'était déja posé

[alex.]

Si tu passes par le command center, il me semble que tu as aussi un panel d'options dont une concernant l'autocommit.

Alex.

[o0arthas0o]

désoler du temps de réponse .
Jamais vu auparavant, possible que j'ai mal regarder, donc j'y plonge.
a tt

[o0arthas0o]

Oups, j'avais oublié de repassé ici.
En faite j'ai pu trouver ma réponse.
Il faut se connecter au clp via la commande "db2 +c" qui va annuler l'auto commit.
Sa donne en gros:

c:\path\bin>db2 +c
db2>

Voila voila, j'espere que sa aidera des gens dans un futur prochain

++