En tant que programmeur client, mieux vous connaîtrez le principe de fonctionnement de SQL Server, meilleur sera le code que vous écrirez. Par exemple, pas question d'autoriser une interaction utilisateur au milieu d'une transaction, selon l'avertissement du Tip 7.
Autre médiocre technique de programmation : écrire l'application client pour commencer une
transaction, envoyer une instruction de mise à jour à SQL Server, puis afficher une boîte de messages demandant aux utilisateurs s’ils veulent continuer. Dans ce cas, SQL Server va maintenir les verrous acquis jusqu’à ce que l’utilisateur, lequel est peut-être allé déjeuner ou a quitté son bureau jusqu’au lendemain, revienne et clique sur OK dans la boîte de messages.
Le Tip 5 mettait en garde contre l’utilisation des curseurs du serveur. Cependant, les curseurs clients sont un sujet différent. Programmer l’application client pour traiter en mode ligne à ligne un ensemble de résultats que SQL Server a obtenu grâce à une opération à base d’ensembles, est parfaitement acceptable. Mais il faut lire la documentation de votre API pour optimiser les performances des nombreuses variantes des curseurs clients.
Il existe une variante du curseur client : le curseur Fast Forward-Only, utile pour atteindre des données séquentiellement dans un but de lecture seule ponctuelle (one-time-only-read-only). Grâce à ce curseur, on peut économiser deux allers-retours avec le serveur ; SQL Server atteint la première ligne quand le curseur est ouvert, et ferme le curseur quand SQL Server atteint la dernière ligne. Même si on n’atteint qu’un petit nombre de lignes, si on utilise fréquemment la section faisant intervenir le curseur Fast Forward-Only, les deux allers-retours ainsi économisés s’additionneront.
Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.
