Discussion :

[martin45]

Bonjour,

Je dois convertir une vieille application qui utilisait le BDE et des TTables en ADO avec des TADOTables. J'utilise maintenant un provider Microsoft.Jet.OLEDB.4.0 pour une "base" Access.

Dans certains cas, j'ai le message suivant au moment d'un TADOTable.Post :

La ligne n'a pas pu être trouvée pour la mise à jour. Certaines valeurs ont peut-être changé depuis leur dernière lecture.

Qu'est-ce que ça veut dire exactement ? Aucune valeur n'a pu changer depuis la dernière mise à jour, les tables ne sont ouvertes que par un seul exécutable. Avec le BDE je n'avais pas ce problème.

Je n'ai aucun besoin de cache, ni d'une quelconque optimisation. Les tables ont été définies avec les valeurs par défaut des différentes propriétés ayant à voir avec les optimisations. Peut-être dois-je changer quelque chose pour empêcher tout cache intempestif ?

Merci pour vos suggestions...

[edam]

clé primaire

[martin45]

Est-ce que tu pourrais être un peu plus explicite ?

[edam]

la table destination, a t elle un clé primaire??
normalement cette question était déjà posé

[BuzzLeclaire]

Salut,

Essai de Close; et Open; ta table juste avant ton post.

Et surtout vérifie que tu ne modifie pas la clé primaire si celle-ci est auto-incrémenter une fois qu'elle est créée.
Si tu créer un enregistrement et juste apres tu le modifie tu peux rencontrer ce problème sur les clé primaire auto-incrémenté.

A plus

[Just-Soft]

mais lui il ne dit rien

[martin45]

Bonjour,

La clé primaire n'est pas auto-incrémentée (non supportée sous la version d'Access) et elle n'est pas modifiée, sauf bien sûr après l'insert quand les champs initialement vides sont remplis.

J'avais déja essayé un cancel, et close + open ne change rien non plus.

Le mystère subsiste... je vais continuer à investiguer et sinon je ferai les créations et mises à jour par des TQuery, en maudissant CodeGear.

Merci quand même.

PS : Je ne travaille qu'un jour par semaine sur ce problème, donc soyez patients...

[BuzzLeclaire]

bon,

Est-ce que tu pourrais
1) Donné la liste des champs et leur type
2) envoyé la procédure où l'erreur apparait
3) dans quel cas elle apparait.

bye.

PS : pas de champs auto-incrémenté !!! Ouahhh c'est quel version d'access ????

[martin45]

Bonjour,

Ce serait peut-être un peu long de donner tous les champs. Il y en a 95 dans la table, qui est créée et utilisée par un progiciel.

Cependant, j'ai pu réduire le problème à ce qui suit :

Code :

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

1
2
3
4
5
6
7
8
9
 
Dm.TableEntetesBl.Post;
Dm.TableEntetesBl.Edit;  // Ok, tout va bien
 
Dm.TableEntetesBl.FieldByName('MontantRemise').Value := 0 ;  
// C'est pareil avec : Dm.TableEntetesBlMontantRemise.Value := 0 ;
// ou avec : Dm.TableEntetesBlMontantRemise.AsFloat := 0 ;
 
Dm.TableEntetesBl.Post;  // exception : la ligne n'a pu être trouvée pour la mise à jour...

le champ MontantRemise est un TFloatField, Il n'appartient à aucun index. Il n'y a pas d'événement qui soit déclenché lors de sa mise à jour et toutes ses propriétés, à part le FieldName, sont à leur valeur par défaut.

Dans le datamodule :

Code :

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

1
2
3
4
 
    object TableEntetesBlMontantRemise: TFloatField
      FieldName = 'MontantRemise'
    end

Une idée ? Merci !

[Just-Soft]

Ok, mais y a bien un index pour cette table, ou une relation "active" avec une table maître ?

[BuzzLeclaire]

Salut,

Effectivement 95 champs, y'en à bien un en clé primaire ou null interdit, apparement tu choisi de modifier un seul champ mais qu'adviennent des autres.

c'est peut claire. essai de repérer les champs clé et null interdit et vérifie leur valeur avant le Post;

@+

[martin45]

Dans le source fourni, il y 2 post.

Je n'ai pas mis le code avant le premier post, mais il y a des dizaines de champs qui sont mis à jour. Jusqu'à ce post, inclus, il n'y a pas de problème.

L'exception se produit uniquement lors du second post, après mise à jour du champ 'MontantRemise'. Ce dernier champ n'est pas dans un index et aucun autre champ de la table n'est mis à jour.

Ce qui est vraiment bizarre c'est que, si j'enlève l'assignation de la valeur 0 à ce champ 'MontantRemise', ainsi que le post et l'Edit qui suivent immédiatement, l'exécution se poursuit normalement avec l'assignation de 15 champs (tous TFloatField) et un post final sur la table !

La table en cause, EntetesBl, n'a pas de mastersource assignée et, au moment où le code s'exécute, aucune table n'a une mastersource vers elle.

Si vous y comprenez quelque chose...

[Just-Soft]

Dans le source fourni, il y 2 post.

Ce qui est vraiment bizarre c'est que, si j'enlève l'assignation de la valeur 0 à ce champ 'MontantRemise', ainsi que le post et l'Edit qui suivent immédiatement, l'exécution se poursuit normalement avec l'assignation de 15 champs (tous TFloatField) et un post final sur la table !

je crois que ton diagnostic est bon cette fois-ci
si tu procède pas à pas en commençant par éliminer ce qui dans le Edit et éventuellement les évènements s'il y en a, puis l'assignation mais jamais le Post car c'est ce que tu veux faire.

Toujours à l'écoute alors tiens nous au courant...

[martin45]

je crois que ton diagnostic est bon cette fois-ci
si tu procède pas à pas en commençant par éliminer ce qui dans le Edit et éventuellement les évènements s'il y en a, puis l'assignation mais jamais le Post car c'est ce que tu veux faire.

Toujours à l'écoute alors tiens nous au courant...

Oui, mais je dois garder l'assignation, car le but est bien de mettre à jour le champ correspondant. Il n'y a pas d'événement et donc plus rien à enlever du source que j'ai envoyé...

Je vais essayer de faire les mises à jour avec un TADOQuery pour avancer... mais ça fait beaucoup à écrire et surtout à tester pour un simple changement de pilote de base de donnée.

Merci quand même.

[martin45]

Bonjour,

Pour le premier programme où je rencontrais le problème, je n'ai pas trouvé d'autre solution que faire les mises à jour de certains champs par un TADOQuery (et les autres par Edit, assignation et Post). Heureusement, je n'avais pas besoin de la nouvelle valeur des champs concernés dans la TADOTable dans la suite du programme (une édition de BL).

Par contre je rencontre exactement le même souci ailleurs, et je n'ai pas d'alternative pour l'instant, car j'ai besoin des champs mis à jour dans l'objet TADOTable. Une instruction via Query devrait dans ce cas être suivi d'un Refresh, et cela prend des dizaines de secondes, et pénalise donc beaucoup trop les performances.

Mais enfin, quel est ce problème ? Suis-je le seul à le rencontrer ?

Est-ce qu'il existe d'autres possibilités que ADO pour utiliser des tables Access ?

[martin45]

Bonjour,

Après de longues recherches, j'ai résolu le problème.

Il y a un bug dans ADO et son cache qui ne prend pas bien en compte les champs ayant une valeur par défaut dans MS-Access. Si on créée un enregistrement (.insert ou .append), qu'on ne donne pas une valeur à tous les champs, et qu'on fait un .post, on obtient ensuite et de manière non systématique et aléatoirement le message d'erreur indiqué.

Il semble que les valeurs par défaut données au niveau de MS-Access n'aillent pas dans le cache ou ne le raffraîchissent pas et que cela donne ensuite un conflit, comme s'il y avait eu une mise à jour concurrente... Je n'ai pas MS-Access et je ne sais pas quels sont les champs qui ont des valeurs par défaut dans la base utilisée. Il m'a donc été difficile d'être plus précis.

Je suis seulement arrivé à contourner le bug en donnant une valeur explicite à chacun des champs après mes .insert. Comme il y avait près de 100 champs à assigner dans plusieurs tables j'ai fait la procédure suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
procedure TDmCT.TableAfterInsert(DataSet: TDataSet);
 
var
     i : integer ;
 
begin
     Assert ( Dataset is TAdoTable );
     for I := 0 to Dataset.Fields.Count - 1 do begin
         if Dataset.Fields[i].IsNull then begin
                case Dataset.Fields[i].DataType of
                    ftString,ftWideString,ftMemo : Dataset.Fields[i].Value := ' ';
                    ftSmallint,ftInteger,ftWord,ftFloat,ftCurrency,ftBCD,
                    ftDate,ftTime,ftDateTime,ftBytes,ftVarBytes : Dataset.Fields[i].Value := 0 ;
                    ftBoolean : Dataset.Fields[i].Value := false ;
                    else
                        Assert( false, Dataset.Fields[i].FieldName+' type ?');
                    end; // case
                end ;
            end; // for
     end;

Elle ne traite que les types de données que j'utilise et n'assigne une valeur que si elle n'a pas été déjà assignée par une valeur par défaut dans la TAdoTable, par un lien maître/ esclave ou par un événement OnNewRecord.

En espérant que ce problème, qui n'existait pas avec le BDE, sera corrigé un jour...

Merci à ceux qui ont tenté de m'aider !

[BuzzLeclaire]

Salut,

Incroyable, je viens justement de tombé sur exctement le même message lors d'un ExecSQL sur une requete ADO
En fait je Fais 30 requetes d'un coup (en fin une par une) de type Update et je suis tombé sur ce message.
Et cherché..cherché...cherché...
J'etais persuadé d'un problème de droit d'écriture dans les champs en question.

Et j'ai trouvé, en fait j'utilise un DATAModule dans lequel dans l'evenemt onbeforeconnect, j'initialise ma connection comme ceux-ci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
procedure TDataModule1.ADOCnx1BeforeConnect(Sender: TObject);
begin
  if AccesMDB <> '' then
  Begin
    Try
      ADOCnx1.Provider := 'Microsoft.Jet.OLEDB.4.0';
      ADOCnx1.LoginPrompt := False;
      ADOCnx1.ConnectionString :='Data Source='
      + AccesMDB + 'Mode=Read;Persist Security Info=False';
    Except
      on E : Exception do
      Begin
        ShowMessage(E.ClassName + ' erreur soulevée : '+#13+#10+
        'Message : '  + E.Message       +#13+#10+
        'Unit : '     + Self.ClassName  +#13+#10+
        'Procedure : '+ 'ADOCnx1BeforeConnect'      +#13+#10+
        '-----------------------------------------------------------------------'+#13+#10+
        'Impossible d''acceder à votre logiciel de Devis.'  +#13+#10+
        'Si le problème persiste, merci de contacter votre revendeur');
      end;
    end;
  end;
end;

Elle était là mon erreur :
Mode=Read;
evidement j'ai retirer ce code et dans l'inspecteur d'objet j'ai choisi cmreadWrite

J'ai tourné en rond car au début je ne regardais que dans l'inspecteur d'objet et je n'avais pas remarqué ce paramètre mode en conception !!!

On c'es jamais c'est peut-être votre cas...

[lmsalem]

essayer de supprimer la valeur par defaut attribue au champs dans la table de la base de donnees