Data.Win.ADODB.TADOConnection.CursorLocation
Delphi
property CursorLocation: TCursorLocation read GetCursorLocation write SetCursorLocation default clUseClient;
C++
__property TCursorLocation CursorLocation = {read=GetCursorLocation, write=SetCursorLocation, default=1};
Propriétés
| Type | Visibilité | Source | Unité | Parent |
|---|---|---|---|---|
| property | published | Data.Win.ADODB.pas Data.Win.ADODB.hpp |
Data.Win.ADODB | TADOConnection |
Description
Spécifie si le curseur de la connexion est côté client ou côté serveur.
Utilisez CursorLocation pour indiquer si les curseurs qui utilisent l'objet connexion pour se connecter au stockage de données ADO utilisent une bibliothèque de curseur côté client ou côté serveur. CursorLocation n'affecte que les connexions ouvertes une fois la propriété initialisée. La valeur par défaut de CursorLocation est clUseClient.
Un curseur côté client offre davantage de flexibilité. Toutes les données sont rapatriées sur la machine locale puis manipulées sur place ce qui permet des opérations que ne gèrent normalement pas les serveurs comme trier et retrier les données ou des filtrages supplémentaires. Les instructions SQL sont exécutées par le serveur, donc pour les instructions qui limitent l'ensemble de résultats à l'aide d'une clause WHERE, seul l'ensemble de résultats restreint est renvoyé au curseur local.
Un curseur côté serveur offre moins de flexibilité mais il peut être plus avantageux (voire nécessaire) pour des ensembles de résultats volumineux. L'utilisation d'un curseur côté serveur devient nécessaire quand la seule taille de l'ensemble de résultats excède l'espace disque disponible qui serait nécessaire à la création d'un curseur côté client. De plus, de nombreux serveurs ne gèrent que des curseurs unidirectionnels. Cela interdit de déplacer en arrière le pointeur d'enregistrement dans l'ensemble de données (même d'un seul enregistrement) via l'ensemble d'enregistrements.