FRIHOSTFORUMSSEARCHFAQTOSBLOGSCOMPETITIONS
You are invited to Log in or Register a free Frihost Account!


ADO Définition et description de propriétés de l'objet Recor





DarCom
ADO - Propriétés cursorType, LockType et cursorLocation
Définition et description de propriétés de l'objet Recordset de ADO

L'objet le plus utilisé des objets proposés par ADO (Active X Data object) est certe l'objet recordset. Celui-ci, comme tout autres objet de comporte plusieurs propriétés. Trois d'entre elles, cursorType, cursorLocation et lockType, doivent être bien comprises par le développeur car une mauvaise configuration de celles-ci peuvent affecter considérablement la performance de l'objet. Cet article a pour but d'expliquer le rôle de chacune de ces propriétés ainsi que des valeurs qu'elles peuvent prendre.
Les types de curseur (cursor type)
Le résultat d'une commande SQL de type SELECT exécuté sur une ou plusieurs table d'une base de données quelconque consiste en un regroupement de tous les enregistrements répondant à une certaine condition (clause WHERE de l'instruction). Ce regroupement d'enregistrement (résultat de la requête) est appelé 'result set'. Dépendant de la requête, le 'result set' peut contenir une petite mais souvent une grande quantité d'enregistrements. Les applications ne pouvant pas travailler avec une telle quantité de données pour des raisons de performances doivent recourir à un certain mécanisme pour pouvoir ainsi travailler avec un seul ou encore un petit groupe d'enregistrements provenant du 'result set'.
Le principal but du curseur et de conserver en mémoire la position de l'enregistrement traité en provenance du 'result set'. Ces autres fonctionnalités sont d'indiquer le nombre d'enregistrements retournés dans le 'result set', de déterminer si il est possible de naviguer vers l'avant seulement ou vers l'avant et l'arrière dans le 'result set' (scrollability) et autres..
Voici la liste de ce qui est possible de faire à l'aide d'un curseur:
1. Spécifier la position d'une ligne du 'result set' 2. Utiliser un ou plusieurs enregistrements basé sur une position du 'result set' 3. Modifier les données dans les enregistrements à une certaine position dans le 'result set' 4. Définir un certain degré d'affectation des changements apportés par différents utilisateurs
ADO propose quatre types de curseurs et donc quatre valeurs peuvent être attribuées à la propriété cursorType de l'objet Recordset. Ci-dessous ce trouve la description de chacune de ces valeurs.
1. Curseur Forward-Only (valeur de propriété : adOpenForwardOnly)
Ce type de curseur est le type par défaut de l'objet Recordset c'est à dire que si vous n'indiquez aucune valeur à la propriété cursorType, c'est ce type de curseur qui sera utilisé. Comme son nom l'indique, ce type de curseur ne permet de naviguer que vers l'avant dans le 'result set'. Il ne supporte pas le 'scrolling' (naviguer vers l'avant ainsi que vers l'arrière). Dans certains curseurs de type forward-only toute modification affectant le 'result set' demeurent visibles durant la navigation à travers les enregistrements. Par contre, puisque ce type de curseur ne ce déplace que vers l'avant, les modifications apportées dans les enregistrements situés avant la position courante du curseur ne sont pas visibles. Lorsque les données d'un enregistrement ont été traitées, le curseur libère toute ressource qui avait été utilisée pour les données de celui-ci.
Le curseur forward-only est un curseur qui s'ouvre très rapidement. Si une partie de votre application ne nécessite pas de retour en arrière dans les données, le type de curseur Forward-Only est probablement celui qui sera le plus efficace.
2. Curseur Static (valeur de propriété : adOpenStatic)
Les curseur de type 'static' affiche le 'result set' tel qu'il était au moment de l'ouverture. Dépendant de leur implémentation, ces types de curseur peuvent être read-only ou read/write. La plupart du temps, il implémente le scrolling (navigation avant et arrière). De plus, en général, ces curseur ne permette de détecter que les modifications faites dans le 'result set' en cours de traitement. Il ne pourra en aucun cas, détecter des changements à la base de données concernant les mêmes enregistrements que ceux du 'result set' qui ont été effectués par une autre application.
Si vous faites la création d'une application et que vous savez que celle-ci n'aura pas besoin de détecter les changements apporté à la base durant la navigation dans un 'result set' et que vous croyez nécessaire que la navigation à travers les enregistrement s'effectue dans les deux sens, ce type de curseur s'avèrera le meilleur choix.
3. Curseur Dynamic (valeur de propriété : adOpenDynamic)
Le curseur de type 'dynamic' détecte tout changement apporté aux enregistrements même si le changement est effectué à même le curseur ou par un autre utilisateur (qui n'utilise pas le même curseur). De plus, le curseur de type 'dynamic' permet de naviguer dans les deux sens dans le jeu d'enregistrements.
Si l'application que vous développez doit détecter absolument tous les modifications effectuées par tous les utilisateurs connectés à la base de données, ce type de curseur est le plus adéquat.
4. Curseur KeySet (valeur de propriété : adOpenKeySet)
Le procédé utilisé avec un tel type de curseur est le suivant : Une clé est construite et sauvegardé coté client ou coté serveur pour chaque enregistrement. Lorsque l'application accède à une ligne, la clé est utilisée pour trouver les données à partir de la source de données. Lorsque le 'result set' est entièrement peuplé, les additions ou les mises à jours qui affectes le 'result set' ne fait plus partie de celui-ci tant qu'il n'est pas fermé et ré-ouvert.
Ce type de curseur est en quelque sorte un intermédiaire entre les types de curseur static et dynamic.
Emplacement du curseur (cursor location)
Tout curseur utilise certaines ressources pour stocker ses données. Celles-ci peuvent être un fichier temporaire sur le disque, de la mémoire vive ou encore un espace temporaire d'une base de données. Il existe deux types d'emplacement pour un curseur soit : coté client ou coté serveur. On accorde la valeur adUseClient à la propriété cursorLocation pour déterminer que le curseur utilisé sera de type client et logera donc les données temporaires à l'aide de ressource sur l'ordinateur client. Pour définir le curseur comme étant de type serveur, on ajuste la propriété cursorLocation à adUseServer.
Considération
Il peut s'avérer une mauvaise idée d'utilisé un emplacement client pour le curseur lorsque vous utilisé un curseur de type Keyset ou dynamic. En effet, si votre 'result set' comporte énormémment d'enregistrements, ceci pourrait affecter considérablement les ressources du client. Le grand avantage d'un emplacement client s'est lorsque les données ont été téléchargées dans l'ordinateur client, la navigation à travers celle-ci est très rapide. De plus, les ressources utilisées n'encombrent pas le serveur.
L'utilisation d'un emplacement coté serveur peut être bénéfique dans le sens où seulement les enregistrements demandés par le client sont envoyés via le réseau. Cela évite les encombrements sur le réseau. Il devient très important de ce demander par contre si les ressources du serveur conviendront à vos ou votre curseur.
Type de verrouillage (lock type)
Le verrouillage est le processus exécuté par DBMS pour restreindre l'accès à un enregistrement dans un envirronement où interviennent plusieurs utilisateurs (multi-user). DBMS signifie DataBase Management System. Un DBMS est un logiciel utilisé pour la gestion de l'information d'une base de données comme par exemple Microsoft SQL Server.
Lorsqu'un enregistrement est verrouillé, cela signifie qu'aucun autre utilisateur que celui concerné par le verrouillage ne pourra exécuter un changement sur celui-ci. Ceci permet d'empêcher que deux utilisateurs mettent à jour un enregistrement au même moment.
Il se doit de jouer de prudence lorsque l'on verrouille des données. Par exemple, si vous savez qu'à chaque instant, plus d'un utilisateur pourrait demander d'accéder à un enregistrement, et qu'un processus de verrouillage a été adopté, il peut en résulté en une perte considérable de performance. Il convient donc de verrouiller les données en cas d'un réel besoin.
La propriété lockType de l'objet Recordset peut accepter 5 valeur différentes. Les voici avec une courte définition de chacune:
adLockUnspecified
Ne spécifit aucun type de verrouillage
adLockReadOnly
Les données ne peuvent être altérée. C'est le type de verrouillage le plus rapide.
adLockOptimistic
Les données sont verrouillées seulement à l'appel de la méthode Update. Cela signifie qu'il y a tout de même une chance pour que les données soit modifiées entre le moment où l'utilisateur commence à éditer les données et procède à l'appelle de la méthode Update.
adLockPessimistic
Le 'Provider' verrouille les données généralement dès le début de l'édition de celles-ci pour être certain de la réussite de l'opération. Par contre les données en question restent indisponible sur une plus longue période.
adLockBatchOptimistic
Indique une mise à jour par lot de données. Cette valeur est requise seulement lors de l'utilisation d'un 'batch update mode'.
Related topics
Comment poster votre message et en quelle langue
Mon projet? on en discute?
Les MMORPG...que choisir?
installer un cms avec fantastico
Quel antivirus utilisez vous ?
Débat: Pour/Contre les OGM???
WOW je suis à la recherche de connaisseur
Mountyhall: bienvenue sur la terre des trolls
Refoirage frihost ?
Les philosophies politiques françaises
Occaz pour les footeux
[Guide] Les services windows (2000, XP) optimisations.
10 astuces pour accélérer Windows XP
hebergement
Reply to topic    Frihost Forum Index -> Language Forums -> French

FRIHOST HOME | FAQ | TOS | ABOUT US | CONTACT US | SITE MAP
© 2005-2011 Frihost, forums powered by phpBB.