Certaines valeurs ont peut-être changé depuis leur dernière lecture

Version imprimable

26/11/2007, 21h51
salimdz

Certaines valeurs ont peut-être changé depuis leur dernière lecture

bonjour,
j'ai un programme Client / Serveur qu'est utilise une base de donnée SQL Server,
j'ai de temps en temps ce message d'erreur "La ligne n'a pas pu être trouvée pour la mise à jour. Certaines valeurs ont peut-être changé depuis leur dernière lecture"
je cherche à trouvé une solution à ca ou comment je peut faire suivi d’exception global pour évité ce message
merci d’avance
27/11/2007, 15h07
ShaiLeTroll

Tu dois avoir un problème de clé, normalement une ligne est identifié par sa clé primaire, qui ne doit pas être modifé par la suite (du moins sans s'exposer à un des gros soucis selon les bases), en général c'est un Entier Auto-Incrémenté (Trigger)

Utilises-tu des transactions pour englober un ensemble de modification ? Si oui, une transaction doit être ouverte et refermer dans de court délai, sans attendre d'intervention humaine (donc après la saisie)
27/11/2007, 21h29
salimdz

Citation:

Envoyé par ShaiLeTroll

Tu dois avoir un problème de clé, normalement une ligne est identifié par sa clé primaire, qui ne doit pas être modifé par la suite (du moins sans s'exposer à un des gros soucis selon les bases), en général c'est un Entier Auto-Incrémenté (Trigger)

Utilises-tu des transactions pour englober un ensemble de modification ? Si oui, une transaction doit être ouverte et refermer dans de court délai, sans attendre d'intervention humaine (donc après la saisie)

je n'utilise pas des transactions, j'ai utilise ADOTable sans transactions
28/11/2007, 10h47
edam

Citation:

Envoyé par salimdz

je n'utilise pas des transactions, j'ai utilise ADOTable sans transactions

utlise plutot adodataset et comme ta dit ShaiLeTroll soit tu n'as pas un index primére soit que ton index utilise plus d'un champs (modfiable)
29/11/2007, 01h28
salimdz

Citation:

Envoyé par edam

utlise plutot adodataset et comme ta dit ShaiLeTroll soit tu n'as pas un index primére soit que ton index utilise plus d'un champs (modfiable)

merci pour votre réponse,
je doit change tous mes ADOTable avec des ADODataSet
c'est vrai mon index utilise plusieurs champs modifiable
01/12/2007, 14h12
hmhm12

j ai rencontre ce pb avec les ADO,
la solution que j ai fait est ;

Code:

adotable1.active=false;adotable1.active=true;
04/12/2007, 21h56
salimdz

salut,
j'ai changer le type de verrou à pessimiste dans ADOTable
mais il faut un peut de temps pour voir les résultats
04/12/2007, 22h06
salimdz

Citation:

Envoyé par hmhm12

j ai rencontre ce pb avec les ADO,
la solution que j ai fait est ;
adotable1.active=false;adotable1.active=true;

merci, pour votre réponse,
j'ai pas essayer cette solution, mais t'ajoute au c'est ligne de code
06/12/2007, 00h28
colfire_dev

Mettez locktype à ltBatchOptimistic l'erreur ne s'affiche plus, mais un autre probleme se pose; le post à l'air de bien marcher mais il ecrit rien ds la table, à l'ecran ca à l'air de passer mais en vrai rien ne se fait. Een tout cas parapport à MYDAC c le jour et la nuit:lol:
06/12/2007, 00h30
colfire_dev

je vous signale que j'utilise Delphi2007 update3 et ADO mais avec MYDAC j'utilise mon vieux Delphi7. A l'occasion y a il qqn qui a Mydac pour Delphi2007
06/12/2007, 22h13
salimdz

Citation:

Envoyé par colfire_dev

Mettez locktype à ltBatchOptimistic l'erreur ne s'affiche plus, mais un autre probleme se pose; le post à l'air de bien marcher mais il ecrit rien ds la table, à l'ecran ca à l'air de passer mais en vrai rien ne se fait.

Comme ca il y a un problème la perte des données, mais ça très c’est grave
11/12/2007, 22h34
salimdz

Citation:

Envoyé par salimdz

salut,
j'ai changer le type de verrou à pessimiste dans ADOTable
mais il faut un peut de temps pour voir les résultats

salut
la solution n’a pas marche (type de verrou à pessimiste),
le programme il se bloque le temps qu’un 2 poste veux l’exécuté
03/01/2010, 12h16
kachwahed

Bonjour, il parait que j’arrive en retard, bon… désolé ;)

J’ai remarqué que ce genre d’erreurs ne se pose généralement-que si on utilise des champs Auto-incrément.

Le jeu d'enregistrements ADO conserve une copie des valeurs origines qui ont été retournés à partir de la base de données. Lorsque le client met à jour des enregistrements déconnecté localement, la valeur est modifiée et la valeur origine reste inchangée, pour refléter la valeur qui a été à l'origine dans la base de données… bla bla bla

En résumer le problème situé au niveau de la propriété CursorLocation mettez la clUseServer et les valeur se mettre a jours après chaque déplacement dans votre TDataSet.
Si vous êtes obligez d’utiliser clUseClient, alors il faut faire un MAJ pour votre TDataSet pour que les données soient…, comme ceci:

Code:

DataSet.Refresh;

Il faut juste choisissez le bon évenement pour ce ci, comme BeforeScroll par exemple.
Pour plus d’info visiter :
http://support.microsoft.com/kb/q193515/
Bonne continuation.
Cordialement Kachwahed.
07/01/2010, 16h57
salimdz

merci pour cette réponse
je doit essayer pour voir
08/01/2010, 00h01
BuzzLeclaire

Salut,

Il faudrait quand même savoir quelle opération tu fais sur la table. (A moins que je sois :calim2: je l'ai pas vue...)

Généralement cette erreur proviens lorsqu'on cherche à ajouter un enregistrement et que l'on essai d'écrire sur le champs AUTOIncrement, ou que l'on essai de mettre à jour (modifier) ce champs.

Il faut pas y toucher, si tu créer un nouvel enregistrement ne renseigne pas ce champs cela se fera tout seul.

J'espère que cette piste t'aidera.
08/01/2010, 19h08
salimdz

merci,
le problème il déclenche le temps qu'il y a plusieurs clients utilisent le même enregistrements
11/01/2010, 20h33
Just-Soft

Citation:

Envoyé par salimdz

merci,
le problème il déclenche le temps qu'il y a plusieurs clients utilisent le même enregistrements

et comment fais-tu dans ce cas ?
il faut isoler les MAJ pour pouvoir les traiter. il me semble que tu laisse ça se faire tout seul donc faut s'attendre à toute sorte de bizarrerie. les transactions sont faites pour ça.

donne une description d'une MAJ ; ajout d'une ligne par exemple avec code si possible :oops:.
03/01/2012, 09h56
kachwahed

J'ai eu le même problème une fois avec un champ dont sa valeur se génère par défaut avec SQLServer2005, j'ai résolu le problème en supprimant la valeur par défaut.

Citation:

supprimant la valeur par défaut

Si on veut préserver la valeur par défaut dans BDD, on utilise la propriété dynamique ‘Update Resync’, ça marche seulement pour avec adUseClient :
Code:

1 2 3 4 5 procedure TForm1.ADODataSet1AfterOpen(DataSet: TDataSet); begin TCustomADODataSet(DataSet).Recordset.Properties['Update Resync'].Value := adResyncAutoIncrement + adResyncUpdates + adResyncInserts; end;
en savoir plus: Update Resync Property-Dynamic (ADO)

Code:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms676738%28v=vs.85%29.aspx

20/01/2012, 14h25
ShaiLeTroll

Tu as juste 2 ans de retard sur Just-Soft
et 5 ans sur la question d'origine !
Mais comme ta réponse est plutôt pas mal, disons que c'est une exhumation intéressante !

une autre solution c'est de ne pas utiliser Post() du TADODataSet qui construit un WHERE absolument infâme et de faire soit même les SQL en utilisant uniquement les clés primaires !
Tout dépend aussi de la considération de l'accès concurrentiel, ce mécanisme a pour but de protéger contre la modification à partir de données obsolètes
Perso, je me suis jamais trop soucié de cela, c'est le dernier qui parle qui a raison !

Sinon effectivement Recordset.Resync permet d'effectuer réconciliation !

Nous avons discuté de cela assez récemment dans insert DBGrid avec TADOQuery et requete avec jointure