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,

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