cerhu > microsoft.* > microsoft.dotnet.adonet

Philippe (17/09/2007, 12h00)
Bonjour a tous
J'utilise un dataset pour récupérer des données d'un serveur SQL
Sur certains enregistrements déjà existant dans la base lorsque je récupère
un de ces enregistrements et que je le modifie ne serait-ce que sur un seul
champ ADO me renvoi le message suivant "Violation de l'accès concurrentiel"
je suis en mode de développement et je suis sur que aucune mise a jour n'a
étét faite entre-temps sur la base de données

quelqu'un a t'il déjà eu ce problème ?
merci d'avance pour vos réponses
Gilles TOURREAU (17/09/2007, 12h07)
Le Mon, 17 Sep 2007 12:00:00 +0200, Philippe
<Philippe> a écrit:

[..]
> étét faite entre-temps sur la base de données
> quelqu'un a t'il déjà eu ce problème ?
> merci d'avance pour vos réponses


Avez-vous des champs de type float ou money dans votre table SQL Server ?

Cordialement
Philippe (17/09/2007, 12h24)
Non aucun champ de ce type
Gilles TOURREAU (17/09/2007, 12h29)
Le Mon, 17 Sep 2007 12:24:00 +0200, Philippe
<Philippe> a écrit:

> Non aucun champ de ce type


Utilisez-vous des commandes automatiquement générés dans votre DataAdapter
(SqlCommandBuilder) ?

Cordialement
Patrice (17/09/2007, 12h34)
Faire une trace pour voir l'instruction effectuée.

Le verrouillage optimiste marche en mettant dans la clause where les valeurs
originales des champs :
- si la ligne est trouvée, c'est qu'elle n'a pas été modifiée entre temps et
tout va bien
- si la ligne n'est pas trouvée, c'est qu'elle a été modifiée entre temps
par qq d'autre

Cela peut arriver aussi en cas de perte de précision (par exemple sur un
champ DATETIME).

Soit :
- vérifier l'instruction poour voir où se situe le problème et
éventuellement corrigé (par exemple en ne stockant pas une précision trop
importante dans un champ datetime)
- il est également posisbile d'utiliser un champ timestamp (modifié
automatiquement à chaque update) et ADO.NET utilise alors uniquement ce
champ pour faire son test

(attention au groupe, c'est ADO.NET ? Si ADO tout cours peut-être assyé un
autre groupe même si dans ce cas le principe reste le même).
Philippe (17/09/2007, 12h42)
Non
Gilles TOURREAU (17/09/2007, 12h50)
Le Mon, 17 Sep 2007 12:42:02 +0200, Philippe
<Philippe> a écrit:

> Non


C'est certainement votre requête UPDATE que vous associé dans votre
DataAdapter qui ne modifie aucune ligne dans votre base de données...

Vérifiez via le Profiler de SQL Server, si la requête envoyée est
correcte...

Cordialement
Philippe (17/09/2007, 13h20)
Merci Patrice de tes pécisions
J'utilise bien des champs DateTime de type smallDateTime le problème vient
peut-être d'ici, mais pourquoi (alors que je ne touche pas a ces champs ) le
serveur me renvoit-il une erreur
Je ne peut pas utilisé le timestamp car les valeurs que je dois stocker sont
extraites d'un autre fichier
l'instruction update me parait correct et de plus cette erreur ne se produit
pas sur tous les enregistrements
qu'elle serait la méthode la^plus approprié pour stocker ces dates?
Cordialement
Patrice (17/09/2007, 13h43)
Vérifie si ce champ ne stocke pas des valeurs avec une précision plus grande
que ce dont tu as réellement besoin (par exemple à 3 millisecondes prêts
alors que seules les secondes t'intéressent).

Si oui, il se pourrait que cette précision dépasse la précision du
System.DateTime correspondant et que la valeur originale mémorisée soit donc
tronquée ce qui empêche ensuite la clause WHERE de fonctionner correctement.

Le champ timestamp auquel je fais allusion est un champ supplémentaire non
utilisé par l'application et qui jouera alors le rôle de "version" pour la
ligne (car changé automatiquement à chaque update).

Voir :
[..]
Philippe (17/09/2007, 13h54)
Je vais essayer de tester tout cela
Merci encore
Discussions similaires
acces concurrentiel au fichier

violation de l'accès concurrentiel

violation de l'accès concurrentiel

violation de l'accès concurrentiel.


Fuseau horaire GMT +2. Il est actuellement 14h15. | Privacy Policy