Discussion :

[bambi98]

Bonjour à tous les developeurs
je suis entrain de travailler sur l'acces aux donnée avec ADO. et il ya des point d'ombre dont j'ai besoin d'eclaicissement.
en effet voici mes preocupations
1. la synchronisation d'un recordset: quel avantage utiliser une connexion asychrone par rapport à une connexion synchrone? quand fautil choisir l'un au lieu de l'autre?
2. faisant une programmation evenementielle du recordset est ce que les evenements tels que willmove, movecomplete se declenche automatiquement? si oui comment est ce que celà fonctionne?
3.comment choisir entre les evenements willchangeFields,willmove,Willchangerecord et willchangerecordset pour pouvoir annuler une opération qui a été effectuée? Ici je suis un peu confus car dans les tutos tous ont le meme objectif.
4. enfin j'aimerais avoir des explications, du moins plus claires,sur la difference entre les propriétés value,underlyingvalue,originalvalue de l'objet Field.
merci de votre reponse

[bidou]

1. la synchronisation d'un recordset: quel avantage utiliser une connexion asychrone par rapport à une connexion synchrone? quand fautil choisir l'un au lieu de l'autre?

C'est fondamentalement une question de stratégie. Si tu n'as pas besoin que toutes les données soit traitées pour que la suite de ton code puisse s'exécuter, une connexion asynchrone et plus ntéressante puisque la lourdeur du traitement ADO est masquée.

2. faisant une programmation evenementielle du recordset est ce que les evenements tels que willmove, movecomplete se declenche automatiquement? si oui comment est ce que celà fonctionne?

Si ton Recordset supporte les évènements(WithEvents) ca se déclenche automatiquement. Dans le cas de ces deux évènements, le premier se déclenche lorsqu'une méthode va faire changer la position courante, le second se déclenche lorsque la position à changée. Il faut lire l'argument adReason pour savoir qu'elle méthode demande le changement de position.

3.comment choisir entre les evenements willchangeFields,willmove,Willchangerecord et willchangerecordset pour pouvoir annuler une opération qui a été effectuée? Ici je suis un peu confus car dans les tutos tous ont le meme objectif.

WillMove et WillChangeRecordset ne sont normalement pas utilisés pour annuler les opérations de mise à jour.
Les deux autres vont dépendre globalement de ta stratégie d'annulation. Si tu veux pouvoir sur un même enregistrement annuler certaines modifications de champs et en valider d'autres, tu utiliseras WillChangeField, si ta stratégie au niveau de l'enregistrement est de type tout ou rien, tu préfèreras WillChangeRecord

4. enfin j'aimerais avoir des explications, du moins plus claires,sur la difference entre les propriétés value,underlyingvalue,originalvalue de l'objet Field.

Soit un objet field appartenant à un enregistrement. Il va posséder trois valeurs définies telle que :
Value = Valeur en cours
UnderlyingValue = Valeur dans la source de données
OriginalValue = Valeur lors du remplissage original du champ.

Prenons l'exemple suivant. Mon objet Field contient la valeur 3 lors du remplissage du recordset. A ce moment, les trois propriétés sont égales.
J'affecte 2 à la valeur du champ. A ce moment, Value vaut 2, OriginalValue et UnderlyingValue valent toujours 3. Je met à jour mon Recordset. UnderlyingValue et Value valent alors 2. OriginalValue vaudra 3 si le recordset n'esr pas resynchronisé, 2 sinon

[bambi98]

Bonjour Bidou
Je te remercie d'entrée pour toutes ces explications qui ont veritablement éclaici les points d'ombre.
je vais seulement te poser d'autres questions pour en savoir encore plus

C'est fondamentalement une question de stratégie. Si tu n'as pas besoin que toutes les données soit traitées pour que la suite de ton code puisse s'exécuter, une connexion asynchrone et plus ntéressante puisque la lourdeur du traitement ADO est masquée.

je me demande ici s'il n'ya pas risque d' erreurs tels que des conflits d'utilisateurs ,des transactions qui se confondent,ou autres qui peuvent se produire.

Si ton Recordset supporte les évènements(WithEvents) ca se déclenche automatiquement. Dans le cas de ces deux évènements, le premier se déclenche lorsqu'une méthode va faire changer la position courante, le second se déclenche lorsque la position à changée. Il faut lire l'argument adReason pour savoir qu'elle méthode demande le changement de position.

Si le recordset execute une instruction SQL (par exemple un INSERT INTO plutot que ADDNEW)est ce que les evenements vont toujours se déclencher?
Merci pour ta reponse

[bidou]

je me demande ici s'il n'ya pas risque d' erreurs tels que des conflits d'utilisateurs ,des transactions qui se confondent,ou autres qui peuvent se produire.

Les transactions peuvent toujours comporter un risque selon leurs niveaux d'isolation. Si celui- ci est faible, alors les opérations asynchrone peuvent en effet présenter une lecture sale partielle. Pour ce qui est du multi utilisateurs, c'est normalement sans influence

Si le recordset execute une instruction SQL (par exemple un INSERT INTO plutot que ADDNEW)est ce que les evenements vont toujours se déclencher?
Merci pour ta reponse

Un recordset ne doit en théorie pas exécuter de requête action, et en tout état de cause la simple exécution d'une commande ne déclenchera pas d'évènement sauf si tu es en asynchrone ou que tu refais un Open