bug Post dans un ADOQuery après un InsertRecord

Salut,

Je me replonge dans un vieux bout de programme qui marchait (dans mes souvenirs...), et là ça marche plus... :-\ Le pb vient d'un Post dans un adoquery, précédé par un insertrecord :
j'ai une TDBCtrlGrid, un bouton insérer, un bouton valider. Dans le onclick du bouton insérer, je ne fais qu'un insertrecord avec deux valeurs prédéfinies, et dans le onclick du bouton valider je ne fais qu'un "if adoquery1.State in dsEditModes then adoquery1.Post"
Le insertrecord se fait bien, mais si l'utilisateur modifie ensuite une cellule tdbedit de la ctrl grid, puis clique sur valider, j'ai une EOleException "la ligne n'a pas pu être trouvée pour la mise à jour".
J'ai dû loupé quelque chose... mais vois pas quoi ! La base Access possède bien une clé primaire pourtant. Cherché sur le web mais pas trouvé, vous avez une idée ?

Merci beaucoup !

--

Thibaud

Salut

J'ai eu le même problème.
La clé primaire a du changée dans ton InsertRecord.
Ton InsertRecord fait un Post. Utilise plutot Insert (qui ne fait pas de post)ainsi ton enregistrement ne va pas changer d'état.

Ou alors il faudrait que tu fasse ton insertrecord et que tu recharge ton dataset. en utilisant DisableControls/EnableControls et les bookmark pour que ton rechargement soit transparent.

Ou alors tu as une requete avec une jointure ?

En fait, donne nous ta requete, ce sera plus simple.

Fox

Salut, merci pour ta réponse. La requête est un simple select * sur la table ! Je fais un insertrecord sur les deux premiers champs, le 1er étant un entier long (pas autoincrémenté), clé primaire. Dans la base au lancement de ce prog de test, il n'y a bien-sûr pas d'enregistrement dont la valeur du 1er champ est 10.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

procedure TForm1.Button1Click(Sender: TObject); begin with adoquery1 do begin SQL.Clear; SQL.Add('SELECT * FROM chantiers'); Open; end; end;   procedure TForm1.Button2Click(Sender: TObject); begin adoquery1.InsertRecord([10, 'tutu']); end;   procedure TForm1.Button3Click(Sender: TObject); begin adoquery1.Post; end;

---

Ca plante tout autant avec un insert plutôt qu'un insertrecord, et j'avoue que fermer puis rouvrir ma table, ça me plaît pas trop...
Je reformule mon problème que j'ai simplifié : quelqu'un peut me dire pourquoi le 2e Post (ci-dessous) provoque l'erreur "la ligne n'a pas pu être trouvée pour la mise à jour (...)" ? Pourtant j'ai bien une clé primaire ! Quelque chose doit m'échapper ?

(le champ 0 est de type autoincrémenté, c'est ma clé primaire)

Code:

---

1 2 3 4 5 6

adoquery1.Insert; adoquery1.Fields[1].AsString := 'tutu'; adoquery1.Post; adoquery1.Edit; adoquery1.Fields[3].AsInteger:= 4125; adoquery1.Post // plantage ligne non trouvée pour mise à jour !;

---

ce code sert à illustrer le bug de mon appli. :
- l'utilisateur clique sur mon bouton "insérer" (qui fait un insert et prérempli un champ),
- puis il clique sur valider (un simple Post),
- puis modifie une cellule (d'une dbctrlgrid) numérique du nouvel enregistrement (bizarrement ça passe avec un champ string !),
- puis re-valide : ça plante ! "Ligne non trouvée pour la mise à jour blabla"

Et le code ci-dessus reproduit ce phénomène. Bizarre que ça passe si on remplace l'avant-dernière ligne par adoquery1.Fields[2].AsString:= 'toto' (où le champ 2 est de type chaîne) ! Je précise qu'aucun de ces champ n'est requis.

Une idée ?
Merci !

--

Thibaud

Ca voudrait dire que tant que ton programme n'a pas la clé primaire autoincrémentée (car ton premier post ne lui donne pas), il utilise tous les champs entiers pour identifier l'enregistrement.

Je vais regarder s'il y a un moyen de lui indiquer la clé primaire sans avoir à recharger ton select.

En attendant, essaye de faire un applyupdate juste après ton premier post.

ps : c'est quoi ta base de donnée ? Access ?

Citation:

---

Ca voudrait dire que tant que ton programme n'a pas la clé primaire autoincrémentée (car ton premier post ne lui donne pas), il utilise tous les champs entiers pour identifier l'enregistrement.

---

Oui j'ai cru comprendre à peu près ça en cherchant sur le web. Il utiliserait donc le champ numérique pour identifier l'enregistrement.
C'est effectivement une base Access, et je pense qu'il s'agit peut-être d'un problème de valeur par défaut de ce champ, pourtant j'ai choisi default 0 sous Access !

Je vais essayer avec l'applyupdate comme tu le suggères. Sinon j'ai trouvé un lien intéressant qui indique comment choisir les colonnes à utiliser pour un update http://support.microsoft.com/default.aspx?scid=kb;EN-GB;q190727&GSSNB=1
On voit comment un Post est en fait transformer en requête UPDATE, utilisant les valeurs des colonnes pour identifier l'enregistrement.

Quand-même fou qu'on puisse pas faire

Code:

---

1 2 3 4 5 6

adoquery1.Insert; adoquery1.Fields[1].AsString := 'tutu'; adoquery1.Post; adoquery1.Edit; adoquery1.Fields[3].AsInteger:= 4125; adoquery1.Post // plantage ligne non trouvée pour mise à jour !;

---

simplement ! Cette table est pourtant toute "nue" je l'ai créée pour le test. Juste un champ autoinc(clé primaire), deux champs textes et un champ entier...

Je te tiens au courant
merci de ton aide

Thibaud

okay j'ai trouvé !

Il fallait que le champ numérique n'ait pas de valeur par défaut.
En laissant 0 pour "default value" sous Access, ça plante
en supprimant le 0 ça passe

les voies d'Access (ou de Jet ?) sont impénétrables...