Discussion :

[geros]

Bonjour,

dans un projet DELPHI 7 s'appuaynt sur une basse ACCESS

J'utilsie JET , j'ai configuré mon adoconnection comme suit :
Attributs commiretaining et abortretaining à false.
connect options : coConnectUnspecified
CrusorLocation :clUseClient
IsolationLevel : ilCursorStability
Mode : cmUnknown
Name :ADOConJEt
Provider :Microsoft.Jet.OLEDB.4.0

Mon adoquery :
Cursor location: clUseClient
cursor type:ctStatic
LockType:ltOptimistic
Marshalloptions:moMarshalAll

Lors de la validation, de manière aléatoire, un de mes clients a le message :
"La ligne n'a pas pu être trouvée pour la mise à jour. Certianes valeurs ont peut être changées depuis leur derniere lecture"

J'ai remplacé le post par une requete de mise à jour, même problème.

Pouvez vous m'aider svp, je susi un peu sec.

Meric d'avance.

Pour une fois que je me passe du BDE, c'etts la cata

G.

[Hauwke]

...
Lors de la validation, de manière aléatoire, un de mes clients a le message :
"La ligne n'a pas pu être trouvée pour la mise à jour. Certianes valeurs ont peut être changées depuis leur derniere lecture"
J'ai remplacé le post par une requete de mise à jour, même problème.

Meric d'avance.

Pour une fois que je me passe du BDE, c'etts la cata

G.

Bonjour,
Généralement, ce genre d'exception est levée sur une structure Maître/Détail lorsque la table maître a "un trou". c'est à dire lorsque les bases ne sont pas compactées lors de la déconnection et qu'une opération d'insertion a été interrompue intempestivement.
Voyez du coté de la structure de la table et employez les transactions pour vos opérations de mise à jour.
Autre cause possible : vous employez des composants qui implémentent un système de contrôle de données, comme les grilles DEVEXPRESS par exemple. Dans ce cas, vous ne devez pas faire vos post sur la table directement mais utiliser le "datacontroller.post" de votre composant.
Cordialement,
Hauwke

[delphi-fan]

Bonjour,

Je viens d'avoir le même problème avec une table Access que j'alimente par ADO et que je visualise, puis finis de compléter manuellement sur une grille . Après avoir fait une saisie, cela me plante sur la ligne suivante.

Le problème vient du fait que dans la structure de ma table Access, j'avais un champ numérique où j'avais renseigné une "valeur par defaut" de 0 (mais peu importe le chiffre).
En créant des enregistrements avec Delphi et ADO, je n'avais pas pris la peine d'initialiser ce champ. Delphi le considère alors comme "null", alors que Access voudrait le mettre à la valeur par defaut 0, d'où le message indiquant finalement que "... certaines valeurs ont peut être changé depuis leur dernière lecture".

=> 2 Options si ton champ numérique est mis à jour comme chez moi :

- Dans Access, mettre une valeur par defaut. Mais dans Delphi initialiser le champ aussi ! Cela semble une perte de temps si valeur 0, mais c'est plus propre et est une bonne habitude pour éviter les problèmes.

Code :

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

... FieldByName('xxxxx').Value := 0;

- ou alors tout simplement, ne pas indiquer dans Access de valeur par defaut et tu es libre alors dans Delphi de ne pas initialiser le champ si tu veux.

Voilà. Ton problème doit tourner autour de ça j'espère.

A+

[cmen76]

Bonjour,

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

En fait le message est assez explicite, des données en base ont été modifiées ou supprimées (par un autre dataset), qui empêchent la modification actuelle par le dataset.
exemple un query1.open et un query2.open, sur le même enregistrement en base ; query2.modifie et poste ; alors query1 dispose d'un jeu de données périmé sur lequel il ne pourra plus avoir aucune action.
Cela peut donc venir d'un autre dataset sur le même poste, ou du même dataset mais d'un autre poste, entré en accès concurrent sur le même enregistrement.
Voilà, j'espère que c'est plus clair ainsi...

[edam]

j'opte pour cmen76 ,
c'est pourqoi j'ai réglé le probléme en passant par des requette sql, pas par les composant (TTable,TQuery,...)

[aityahia]

Je vais remonter ce problèmes qui persiste chez moi, un moment donnée j'ai pu régler le problème avec un refrech juste avant l'édition mais avec le temps ma base a prie du volume le refrech me fait défaut il prend un temps considérable.

Je sais pas si quelqu'un a trouvez une solution a ce problèmes.

[aityahia]

j'opte pour cmen76 ,
c'est pourqoi j'ai réglé le probléme en passant par des requette sql, pas par les composant (TTable,TQuery,...)

comment .

[colfire_dev]

comment vous avez fait avec les requetes sql je me trouve bloqué sur le meme probleme

[deutsch]

voila ce que je vou propose :

a mon avis si quelqu'un veut faire une M.a.j il vaut mieux reprendre tt les données et ensuite supprimé l'ancienne et la remplacé par la nouvelle et ceci via une requete

comme tt le monde est content

Bon courage

[edam]

je crois qu'on utlisant TTable et Tquery, à la mise à jour d'un enregistrement il utlise tout les chmps comme clé de recherche
mais avec une requet fait à la "main" tu utilise un clé sur un ou 2 champs qui sencé n'étre jamai modifier durant la vie de la base (auto incrémént par example)
pour ce qui est de réfréche, utilise TclientDataset,