Types de curseurs
Les curseurs de Microsoft SQL Server Compact 4.0 sont similaires aux curseurs utilisés dans SQL Server. Les différences sont documentées dans cette section. Pour une explication complète des curseurs de base de données, consultez la documentation en ligne de SQL Server.
SQL Server Compact 4.0 prend en charge les types de curseurs suivants :
Table de base
Statique
En avance seule
En avance seule/En lecture seule
Jeux de clés
Curseurs de table de base
Les curseurs de table de base représentent le plus bas niveau disponible pour les curseurs. Ces curseurs agissent directement sur le moteur de stockage et sont les plus rapides de tous les types de curseurs pris en charge. Les curseurs de table de base peuvent défiler vers l'avant ou vers l'arrière avec un coût en temps minimal et ils peuvent être mis à jour.
Vous pouvez aussi ouvrir un curseur directement sur un index. Les index sont pris en charge pour classer les lignes d'une table, pour permettre la recherche de valeurs particulières et pour filtrer les lignes sur la base d'une plage de valeurs dans un index.
Les curseurs de table de base sont d'une appartenance dynamique. Cela signifie que deux curseurs ouverts sur la même table peuvent voir immédiatement les insertions, les suppressions et les modifications des données, pour autant que ces deux curseurs se trouvent dans la même étendue de transaction. Dans la mesure où vous pouvez mettre à jour les curseurs de table de base, un client peut utiliser ce type de curseur pour effectuer des modifications sur les données sous-jacentes.
Les curseurs de table de base ne peuvent pas représenter le résultat d'une requête. Les résultats de requêtes telles que SELECT * FROM tablename ne sont pas retournés via un curseur de table de base. C'est un des curseurs de résultat de requête pris en charge qui est utilisé pour cela.
Voici un exemple de la façon d'obtenir un curseur de table de base avec ADO.NET :
//Base Table Cursor
cmd.CommandText = "tablename";
cmd.CommandType = CommandType.TableDirect;
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.Scrollable | ResultSetOptions.Updatable);
Voici un exemple de la façon d'obtenir un curseur d'index avec ADO.NET :
cmd.CommandText = "tablename";
cmd.IndexName = "indexname";
cmd.CommandType = CommandType.TableDirect;
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.Scrollable | ResultSetOptions.Updatable);
Curseurs statiques
Un curseur statique, connu sous le nom de curseur de requête à défilement dans les versions antérieures de SQL Server Compact 4.0, crée et stocke une copie complète de l'ensemble de résultats. L'exception à cela concerne les données de valeur Long, qui sont récupérées quand un utilisateur le demande explicitement. Cet ensemble de résultats est rempli seulement quand c'est nécessaire. Ce fonctionnement est différent de celui de SQL Server, qui remplit l'ensemble de résultats à la création du curseur. Les curseurs statiques prennent en charge le défilement vers l'avant et l'arrière, mais ne prennent pas en charge les mises à jour. Les curseurs statiques ne détectent pas les modifications externes effectuées sur les données qui sont INSENSITIVE. Les résultats des requêtes sont mis en cache pendant la durée de vie du curseur. Si les curseurs statiques ont davantage de fonctions que les curseurs en avance seule, ils sont plus lents et consomment davantage de mémoire. Il est recommandé d'utiliser les curseurs statiques seulement si le défilement est requis et si un curseur de jeux de clés ne convient pas.
Voici un exemple de la façon d'obtenir un curseur statique avec ADO.NET :
cmd.CommandText = "Select * from tablename";
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.Scrollable | ResultSetOptions.Insensitive);
Curseurs en avance seule
Le curseur en avance seule est le curseur le plus rapide parmi ceux que vous pouvez mettre à jour, mais il ne prend pas en charge le défilement. Il prend en charge seulement l'extraction des lignes en séquence, du début à la fin du curseur. Les lignes ne sont pas récupérées de la base de données tant qu'elles ne sont pas extraites. Les effets de toutes les instructions INSERT, UPDATE et DELETE effectuées par l'utilisateur actif ou validées par d'autres utilisateurs, et qui affectent des lignes de l'ensemble de résultats, sont visibles quand les lignes sont extraites du curseur. Le défilement arrière n'étant pas possible sur le curseur, les modifications apportées à une ligne de la base de données après l'extraction de cette ligne ne sont pas visibles via ce curseur.
Les curseurs en avance seule et en avance seule/en lecture seule sont les plus rapides des curseurs de requête. Ils sont recommandés dans les situations où la vitesse et l'empreinte mémoire sont les éléments les plus importants.
Voici un exemple de la façon d'obtenir un curseur en avance seule avec ADO.NET :
cmd.CommandText = "Select * from tablename";
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.Updatable);
Curseurs en avance seule/en lecture seule
Les curseurs avant uniquement/en lecture seule, connus sous le nom de curseurs avant uniquement dans les versions antérieures de SQL Server Compact 4.0, sont les curseurs les plus rapides, mais ils ne peuvent pas être mis à jour.
Voici un exemple de la façon d'obtenir un curseur en avance seule/en lecture seule avec ADO.NET :
cmd.CommandText = "Select * from tablename";
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.None);
Remarque Vous ne pouvez pas créer de curseurs en lecture seule sur une requête qui retourne seulement des colonnes en lecture seule, parce que tous les curseurs SQL Server Compact 4.0 peuvent être mis à jour en interne. SQL Server Compact 4.0 ne peut pas mettre à jour des colonnes en lecture seule retournées dans SqlCeResultSet. Par conséquent, il échouerait avec l'erreur « Impossible de générer un curseur pouvant être mis à jour pour la requête, car il n'existe aucune colonne susceptible d'être mise à jour ».
Curseurs de jeux de clés
Le curseur de jeux de clés de SQL Server Compact 4.0 est un curseur à défilement que vous pouvez mettre à jour. Un curseur de jeux de clés est contrôlé par un ensemble d'identificateurs physiques appelé le jeu de clés. Le jeu de clés est basé sur toutes les lignes qui ont satisfait les conditions de l'instruction SELECT au moment où le curseur a été ouvert. Le jeu de clés est créé dans une table temporaire quand le curseur est ouvert. Avec un curseur de jeux de clés, l'appartenance est déterminée au moment où la requête est exécutée.
Les curseurs de jeux de clés de SQL Server Compact 4.0 sont légèrement différents de ceux de SQL Server. Dans SQL Server, le curseur de jeux de clés utilise un ensemble d'identificateurs uniques comme clés du jeu de clés. Dans SQL Server Compact 4.0, les clés sont des signets indiquant les endroits où les valeurs sont stockées logiquement dans une table. Ce ne sont pas des identificateurs uniques.
S'il est sensible à un certain nombre de modifications, un curseur de jeux de clés ne l'est pas autant que d'autres curseurs. Par exemple, une insertion en dehors du curseur n'est pas détectée, alors que des insertions au sein du curseur seront visualisées à la fin. Dans ce cas, il est recommandé de fermer et de rouvrir le curseur, ou bien d'utiliser un des curseurs en avance seule.
Comme SQL Server Compact 4.0 utilise des signets pour définir un jeu de clés, toutes les modifications apportées aux valeurs des données pour les lignes qui font partie du jeu de clés sont visibles à l'aide le curseur. C'est le cas pour les modifications qui sont faites tant à l'intérieur du curseur qu'à l'extérieur de celui-ci.
Toute suppression dans un curseur de jeux de clés, qu'elle soit dans ou en dehors du curseur, fait que la ligne est signalée comme étant supprimée s'il y a une tentative d'extraction de cette ligne.
Voici un exemple de la façon d'obtenir un curseur piloté par jeu de clés avec ADO.NET :
cmd.CommandText = "Select * from tablename";
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.Scrollable | ResultSetOptions.Updatable);
Utilisation de jointures
Si la requête utilisée pour ouvrir un curseur de jeux de clés comprend des colonnes jointes, ces colonnes ne peuvent pas être mises à jour. L'utilisateur peut insérer de nouvelles valeurs dans ces colonnes, mais les mises à jour ne sont pas prises en charge.
Si le jeu de clé est utilisé pour remplir un contrôle qui peut être mis à jour par l'utilisateur, comme un objet DataGrid, les utilisateurs peuvent essayer de mettre à jour les valeurs du contrôle, et la mise à jour va échouer. Si vous développez une application qui utilise un contrôle DataGrid pour afficher des données de colonnes jointes, vérifiez que vous définissez les colonnes jointes en lecture seule dans le contrôle DataGrid.