Discussion :

[patmaba]

Bonjour,

Lors d'un delete d'un enregistrement dans mon formulaires fait avec Forms6i et généré par designer 6i, en runtime j'obtiens le message suivant :

Could nor reserve record( 2 tries ) Keep Trying ? Qu'est ce que cela signifie ?
Il n'y a pas d'autre personne qui travaille sur l'enregistrement en question qui pose le problème.

Que dois je faire pour résoudre le problème ?

merci.

[SheikYerbouti]

L'enregistrement est verrouillé dans une autre session. peut-être Toad ou Sql*Plus...

[patmaba]

Ben non figure toi.

C'est ce qui me trouble

[SheikYerbouti]

Peut-être un UPDATE manuel quelque part dans le module Forms ?

[bpprive]

Ce message est très clair, c'est à dire qu'il dit que FORMS ne réussi pas à verrouiller l'enregistrement TEL QU'IL EST DANS LE BLOC.

Une des causes possible est qu'effectivement, l'enregistrement en question est bel et bien verrouillé par une autre session, ce qui ne semble pas être votre cas.

Une autre cause possible est que, par exemple, un des champs basé sur la table/vue de votre bloc change au moment d'une commande insert ou update.

Je m'explique. Si vous avez une colonne date_modification dans votre table/vue et qu'un champ CACHÉ de votre bloc soit basé sur cette colonne. Lors de l'insertion, ce champ est alimenté par un trigger qui y inscrit la date du jour. FORMS n'est JAMAIS informé de cette modification. Si vous insérez un enregistrement via FORMS, il vous dira que la transaction s'est exécutée avec succès, mais si vous essayer de modifier l'enregistrement par la suite, vous aurez ce message. Une simple ré-exécution de la recherche dans FORMS et le problème est résolu.

Ce comportement est causé du fait que FORMS essaie de verrouiller l'enregistrement lors d'un UPDATE/DELETE. Pour ce faire, il fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
SELECT [tous les champs du blocs]
  FROM [table sur laquelle le bloc est basé]
 WHERE [PK du bloc = PK de la table]
   AND date_modification = database_value(:bloc.date_modification)

Comme le champ est null dans FORMS et a été alimenté par le trigger dans la BD, FORMS n'est pas informé de cette modification et ne peut donc pas y pallier.

Une des choses à faire pour régler ce problème est par exemple, mettre la propriété VALEUR DE RETOUR DML (DML RETURNING VALUE) à oui. Il y a également d'autre solutions mais moins rapides à implémenter...

En espérant répondre à votre demande

[patmaba]

effectivement j'ai une colonne date avec un default sysdate.

je vais piocher sur ce cas et voir si c'est le problème.

merci

je vous donnerai un feedback.