Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Verrouillage avec Access et SQL Server -> "les données ont été modifiées"

4 réponses
Avatar
Asarus \(Sebastien Candela\)
Bonjour,

J'ai pas mal cherché dans les archives mais je préfère vous poser la
question directement ;-)

Je suis en train de migrer mon appli Access 2000 (partagée en 2 fichiers,
les données et les tables) sous SQL Server. Nous sommes environ 10
utilisateurs dessus.

Suite à cette migration, j'ai procédé à quelques tests et j'ai un problème
récurrent. A plusieurs sur la base, j'obtiens très souvent (5 à 10 fois par
personne pendant un test de 30 minutes) le message "les données ont été
modifiées" et parfois la même chose mais avec l'erreur 7878

J'ai vérifié et personne n'utilisait le même enregistrement au même moment.

Suite à ma recherche, j'ai positionné tous mes formulaires sur le mode de
lock "enregistrement modifié" mais dixit l'aide en ligne ceci n'est pas
valable pour des tables attachées via ODBC (ce qui est mon cas).

A votre avis quelle est la bonne manière de faire pour gérer correctement le
verrouillage au niveau enregistrements avec mes tables attachées SQL Server
?

De plus, j'ai des champs "date" et des champs "heure" parmi mes données et
j'ai lu que le message pouvait venir d'un problème de précision différente
entre access et sql server. Ce qui laisserait croire à Access que les
données ont été modifiées alors qu'il ne s'agit que d'une conversion dans le
bon format par le système. Qu'en pensez vous ?

Merci d'avance ;-)

Seb

4 réponses

Avatar
J-Pierre
Bonjour,

Pour confirmation, utilises-tu des tables SQL attachées ou un projet ADP ?

Ton problème pourrait provenir du fait que le recordset de ton formulaire contient toutes les lignes de ta table, même si tu es en
mode unique (afficher une ligne à la fois), car c'est la technique normalement utilisée avec Access. Autrement dit, tu récupères ton
recordset avec par exemple 5000 lignes, 10 minutes plus tard, tu modifies une ligne, manque de pot, entretemps, un autre a mis cette
même ligne à jour.....

Autre possibilité, quand tu mets une ligne à jour, tu ne fais pas de requery de la source.

Pour autant que je sache, il n'y a pas de verrouillage d'enregistrement au niveau d'Access sauf par code VBA "adLockPessimistic" et
autres. (Ce qui serait extrêment pénalisant si tous les enregistrements étaient verrouillés dès la lecture). Quand un enregistrement
est modifié, SQL répond OK ou bien déjà modifié par un autre.

Il semble qu'il y ait des problèmes de MAJ avec ADP si tu "SET rst = me.recordsetclone" et que tu parcours les lignes de rst.

Et j'en oublie sans doute....

J-Pierre

"Asarus (Sebastien Candela)" a écrit dans le message de
news:3fd84f9f$0$17127$
Bonjour,

J'ai pas mal cherché dans les archives mais je préfère vous poser la
question directement ;-)

Je suis en train de migrer mon appli Access 2000 (partagée en 2 fichiers,
les données et les tables) sous SQL Server. Nous sommes environ 10
utilisateurs dessus.

Suite à cette migration, j'ai procédé à quelques tests et j'ai un problème
récurrent. A plusieurs sur la base, j'obtiens très souvent (5 à 10 fois par
personne pendant un test de 30 minutes) le message "les données ont été
modifiées" et parfois la même chose mais avec l'erreur 7878

J'ai vérifié et personne n'utilisait le même enregistrement au même moment.

Suite à ma recherche, j'ai positionné tous mes formulaires sur le mode de
lock "enregistrement modifié" mais dixit l'aide en ligne ceci n'est pas
valable pour des tables attachées via ODBC (ce qui est mon cas).

A votre avis quelle est la bonne manière de faire pour gérer correctement le
verrouillage au niveau enregistrements avec mes tables attachées SQL Server
?

De plus, j'ai des champs "date" et des champs "heure" parmi mes données et
j'ai lu que le message pouvait venir d'un problème de précision différente
entre access et sql server. Ce qui laisserait croire à Access que les
données ont été modifiées alors qu'il ne s'agit que d'une conversion dans le
bon format par le système. Qu'en pensez vous ?

Merci d'avance ;-)

Seb




Avatar
Sebastien C.
Merci Jean Pierre,

J'utilise bien des tables SQL attachées (via ODBC)..

Pour les requery, j'en fais mais je veux éviter d'en faire de trop car ça
génère du traffic sur le réseau et ralentit sensiblement l'application... il
va peut être falloir que je trouve un moyen de résoudre ceci sans pénaliser
le temps de réponse.

Seb

"J-Pierre" a écrit dans le message de
news:Ov5p$S%
Bonjour,

Pour confirmation, utilises-tu des tables SQL attachées ou un projet ADP ?

Ton problème pourrait provenir du fait que le recordset de ton formulaire
contient toutes les lignes de ta table, même si tu es en

mode unique (afficher une ligne à la fois), car c'est la technique
normalement utilisée avec Access. Autrement dit, tu récupères ton

recordset avec par exemple 5000 lignes, 10 minutes plus tard, tu modifies
une ligne, manque de pot, entretemps, un autre a mis cette

même ligne à jour.....

Autre possibilité, quand tu mets une ligne à jour, tu ne fais pas de
requery de la source.


Pour autant que je sache, il n'y a pas de verrouillage d'enregistrement au
niveau d'Access sauf par code VBA "adLockPessimistic" et

autres. (Ce qui serait extrêment pénalisant si tous les enregistrements
étaient verrouillés dès la lecture). Quand un enregistrement

est modifié, SQL répond OK ou bien déjà modifié par un autre.

Il semble qu'il y ait des problèmes de MAJ avec ADP si tu "SET rst me.recordsetclone" et que tu parcours les lignes de rst.

Et j'en oublie sans doute....

J-Pierre

"Asarus (Sebastien Candela)" a écrit
dans le message de

news:3fd84f9f$0$17127$
Bonjour,

J'ai pas mal cherché dans les archives mais je préfère vous poser la
question directement ;-)

Je suis en train de migrer mon appli Access 2000 (partagée en 2
fichiers,


les données et les tables) sous SQL Server. Nous sommes environ 10
utilisateurs dessus.

Suite à cette migration, j'ai procédé à quelques tests et j'ai un
problème


récurrent. A plusieurs sur la base, j'obtiens très souvent (5 à 10 fois
par


personne pendant un test de 30 minutes) le message "les données ont été
modifiées" et parfois la même chose mais avec l'erreur 7878

J'ai vérifié et personne n'utilisait le même enregistrement au même
moment.



Suite à ma recherche, j'ai positionné tous mes formulaires sur le mode
de


lock "enregistrement modifié" mais dixit l'aide en ligne ceci n'est pas
valable pour des tables attachées via ODBC (ce qui est mon cas).

A votre avis quelle est la bonne manière de faire pour gérer
correctement le


verrouillage au niveau enregistrements avec mes tables attachées SQL
Server


?

De plus, j'ai des champs "date" et des champs "heure" parmi mes données
et


j'ai lu que le message pouvait venir d'un problème de précision
différente


entre access et sql server. Ce qui laisserait croire à Access que les
données ont été modifiées alors qu'il ne s'agit que d'une conversion
dans le


bon format par le système. Qu'en pensez vous ?

Merci d'avance ;-)

Seb








Avatar
Sebastien C.
Bon, j'ai trouvé la cause de mes ennuis... alors j'en fais profiter tout le
monde...

J'ai un formulaire principal me permettant de traiter mes "fiches"
J'ai un bouton qui appelle un formulaire conçu pour l'impression. Il est
assez simple et note la date/heure de première impression et date/heure de
dernière impression.

Le pb c'est que ce formulaire d'impression utilise la même source (ma table
principale) que mon formulaire principal. Quand les dates sont complétées
automatiquement et que je quitte il m'affiche alors "les données ont été
modifiées" car les 2 formulaires étaient ouverts sur le même enregistrement
(par la même personne)

Maintenant, reste à trouver la solution. Je vais voir si je peux éviter ceci
avec une utilisation des vues. Ou bien utiliser un requery à
l'ouverture/fermeture de mon module d'impression...

Seb

"J-Pierre" a écrit dans le message de
news:Ov5p$S%
Bonjour,

Pour confirmation, utilises-tu des tables SQL attachées ou un projet ADP ?

Ton problème pourrait provenir du fait que le recordset de ton formulaire
contient toutes les lignes de ta table, même si tu es en

mode unique (afficher une ligne à la fois), car c'est la technique
normalement utilisée avec Access. Autrement dit, tu récupères ton

recordset avec par exemple 5000 lignes, 10 minutes plus tard, tu modifies
une ligne, manque de pot, entretemps, un autre a mis cette

même ligne à jour.....

Autre possibilité, quand tu mets une ligne à jour, tu ne fais pas de
requery de la source.


Pour autant que je sache, il n'y a pas de verrouillage d'enregistrement au
niveau d'Access sauf par code VBA "adLockPessimistic" et

autres. (Ce qui serait extrêment pénalisant si tous les enregistrements
étaient verrouillés dès la lecture). Quand un enregistrement

est modifié, SQL répond OK ou bien déjà modifié par un autre.

Il semble qu'il y ait des problèmes de MAJ avec ADP si tu "SET rst me.recordsetclone" et que tu parcours les lignes de rst.

Et j'en oublie sans doute....

J-Pierre

"Asarus (Sebastien Candela)" a écrit
dans le message de

news:3fd84f9f$0$17127$
Bonjour,

J'ai pas mal cherché dans les archives mais je préfère vous poser la
question directement ;-)

Je suis en train de migrer mon appli Access 2000 (partagée en 2
fichiers,


les données et les tables) sous SQL Server. Nous sommes environ 10
utilisateurs dessus.

Suite à cette migration, j'ai procédé à quelques tests et j'ai un
problème


récurrent. A plusieurs sur la base, j'obtiens très souvent (5 à 10 fois
par


personne pendant un test de 30 minutes) le message "les données ont été
modifiées" et parfois la même chose mais avec l'erreur 7878

J'ai vérifié et personne n'utilisait le même enregistrement au même
moment.



Suite à ma recherche, j'ai positionné tous mes formulaires sur le mode
de


lock "enregistrement modifié" mais dixit l'aide en ligne ceci n'est pas
valable pour des tables attachées via ODBC (ce qui est mon cas).

A votre avis quelle est la bonne manière de faire pour gérer
correctement le


verrouillage au niveau enregistrements avec mes tables attachées SQL
Server


?

De plus, j'ai des champs "date" et des champs "heure" parmi mes données
et


j'ai lu que le message pouvait venir d'un problème de précision
différente


entre access et sql server. Ce qui laisserait croire à Access que les
données ont été modifiées alors qu'il ne s'agit que d'une conversion
dans le


bon format par le système. Qu'en pensez vous ?

Merci d'avance ;-)

Seb








Avatar
J-Pierre
Salut Sébastien,

Je ne te parle que d'ADP, car je n'ai jamais attaché de tables SQL. Tu devrais peut-être envisager une conversion vers ADP, c'est
plus moderne....

Pour le requery, je crois que tu n'as pas le choix, il faut le faire.
Par contre, il faut le faire intelligemment.

Si la source de ton formulaire est une table, tu vas relire toute la table, d'où de graves problèmes de performances. Dans CHAQUE
formulaire, dans CHAQUE état, il faut ABSOLUMENT avoir une source avec un WHERE ou bien utiliser les propriétés FILTERSERVER (pour
les vues) ou INPUTPARAMETER (pour les procédures stockées).

Dans tous tes formulaires et états dont la source n'a pas de clause WHERE, tu dois dans l'évènement ouverture renseigner la
propriété SERVERFILTER et faire un requery, soit en utilisant un openargs, soit de manière automatique. ConditionWhere d'openForm ne
fonctionne pas.

Un requery bien fait ne coûte pas grand chose.....En tous cas, une requête + un requery qui te ramènent une ou quelques lignes,
c'est moins cher qu'une requête qui te ramène toute la table.

Je sais, c'est franchement chiant à faire, mais si tu ne le fais pas, ne perds pas ton temps à migrer à SQL, avec 10 utilisateurs et
une bonne architecture et conception de base, côté performance, Access est parfait.

J-Pierre - Expert en Source et Requery

"Sebastien C." a écrit dans le message de news:3fd86c4a$0$17124$
Merci Jean Pierre,

J'utilise bien des tables SQL attachées (via ODBC)..

Pour les requery, j'en fais mais je veux éviter d'en faire de trop car ça
génère du traffic sur le réseau et ralentit sensiblement l'application... il
va peut être falloir que je trouve un moyen de résoudre ceci sans pénaliser
le temps de réponse.

Seb

"J-Pierre" a écrit dans le message de
news:Ov5p$S%
Bonjour,

Pour confirmation, utilises-tu des tables SQL attachées ou un projet ADP ?

Ton problème pourrait provenir du fait que le recordset de ton formulaire
contient toutes les lignes de ta table, même si tu es en

mode unique (afficher une ligne à la fois), car c'est la technique
normalement utilisée avec Access. Autrement dit, tu récupères ton

recordset avec par exemple 5000 lignes, 10 minutes plus tard, tu modifies
une ligne, manque de pot, entretemps, un autre a mis cette

même ligne à jour.....

Autre possibilité, quand tu mets une ligne à jour, tu ne fais pas de
requery de la source.


Pour autant que je sache, il n'y a pas de verrouillage d'enregistrement au
niveau d'Access sauf par code VBA "adLockPessimistic" et

autres. (Ce qui serait extrêment pénalisant si tous les enregistrements
étaient verrouillés dès la lecture). Quand un enregistrement

est modifié, SQL répond OK ou bien déjà modifié par un autre.

Il semble qu'il y ait des problèmes de MAJ avec ADP si tu "SET rst > me.recordsetclone" et que tu parcours les lignes de rst.

Et j'en oublie sans doute....

J-Pierre

"Asarus (Sebastien Candela)" a écrit
dans le message de

news:3fd84f9f$0$17127$
Bonjour,

J'ai pas mal cherché dans les archives mais je préfère vous poser la
question directement ;-)

Je suis en train de migrer mon appli Access 2000 (partagée en 2
fichiers,


les données et les tables) sous SQL Server. Nous sommes environ 10
utilisateurs dessus.

Suite à cette migration, j'ai procédé à quelques tests et j'ai un
problème


récurrent. A plusieurs sur la base, j'obtiens très souvent (5 à 10 fois
par


personne pendant un test de 30 minutes) le message "les données ont été
modifiées" et parfois la même chose mais avec l'erreur 7878

J'ai vérifié et personne n'utilisait le même enregistrement au même
moment.



Suite à ma recherche, j'ai positionné tous mes formulaires sur le mode
de


lock "enregistrement modifié" mais dixit l'aide en ligne ceci n'est pas
valable pour des tables attachées via ODBC (ce qui est mon cas).

A votre avis quelle est la bonne manière de faire pour gérer
correctement le


verrouillage au niveau enregistrements avec mes tables attachées SQL
Server


?

De plus, j'ai des champs "date" et des champs "heure" parmi mes données
et


j'ai lu que le message pouvait venir d'un problème de précision
différente


entre access et sql server. Ce qui laisserait croire à Access que les
données ont été modifiées alors qu'il ne s'agit que d'une conversion
dans le


bon format par le système. Qu'en pensez vous ?

Merci d'avance ;-)

Seb