RDO : réception de données à partir de tables temporaires créées par une procédure stockée


Résumé


Il est courant d’avoir des procédures stockées d’utiliser des tables temporaires pour créer un jeu de résultats. Lorsque vous utilisez RDO (objet de données distantes) pour appeler ce type de procédure stockée, il s’affiche comme si le contrôle RDO ne renvoie aucun résultat, qu’un jeu de résultats vide et aucune erreur. Tester cette même requête avec l’utilitaire Microsoft SQL Server version 6,0 ISQL génère les résultats attendus, ce qui vous permet de penser que RDO est limité à la lecture de ces tables temporaires. Ce n’est pas une restriction RDO et RDO peut récupérer les données d’une table temporaire créée dans une procédure stockée. Toutefois, il est impossible de créer un curseur de défilement sur une table temporaire créée au sein d’une procédure stockée. Les tables temporaires créées au sein d’une procédure stockée sont DÉTRUITes à la fin de la procédure stockée. Si ce n’est pas le cas, il n’est pas possible d’ouvrir un curseur de défilement sur la table, et de revenir à celle-ci lorsque l’ensemble de lignes suivant est nécessaire ou lorsque l’utilisateur essaie de mettre à jour, d’insérer ou de supprimer des données. ISQL n’ouvre pas le curseur et n’utilise pas de bibliothèque de curseurs, de telle sorte qu’il lit simplement les données en dehors du canal, une ligne à la fois, en lecture seule, en lecture seule (il s’agit du mode par défaut de DBLIB, de nombreux personnes sont également utilisées pour travailler de cette manière). La bonne nouvelle, c’est que RDO peut également y parvenir. Il vous suffit de faire savoir à SQL Server qu’il n’est pas nécessaire d’ouvrir un curseur côté serveur sur la table temporaire. Pour ce faire, définissez la propriété RowsetSize sur 1 et l’ouverture du jeu de résultats comme transfert uniquement et lecture seule (comme dans ISQL). RDO utilise 100 comme valeur par défaut pour RowsetSize, car il s’agit du paramètre optimal pour la plupart des opérations de curseur et lorsqu’il est défini sur une valeur supérieure à 1, le pilote ODBC de SQL Server doit essayer de créer un curseur côté serveur, car les jeux de lignes Fat nécessitent la possibilité de faire défiler et de mettre à jour. N’oubliez pas que l’utilisation de curseurs est très différente de la taille de jeu de données en lecture seule, en avant-première et en lecture seule, d’une approche permettant de restaurer les données du client. Pour prendre en charge les opérations effectuées par les curseurs (comme le défilement vers l’arrière, le passage des mises à jour positionnées, etc.), la source des données doit être en temps réel pendant la durée de l’ouverture du curseur. RDO peut fonctionner dans un mode de curseur, ou en mode « manche d’incendie », qui vous permet d’effectuer la fonctionnalité souhaitée.

Informations supplémentaires


Exemple de programme

Étape 1 : créer la procédure stockée

Cette procédure stockée crée simplement une table temporaire appelée « #temptest », en la remplissant avec toutes les lignes de la table authors de la base de données pubs.
  1. Ouvrez l’utilitaire ISQL SQL Server 6,0 et remplacez la base de données par défaut par pubs.
  2. Collez le code suivant dans la fenêtre de requête et cliquez sur le bouton exécuter la requête, ou appuyez sur CTRL + E pour exécuter le code Transact-SQL.
       create proc TempTableTest as   select * into #testtemp from authors   select * from #testtemp
  3. Le message de confirmation suivant affiche « cette commande n’a pas renvoyé de données et n’a pas renvoyé de lignes » indiquant que le code Transact-SQL a correctement créé la procédure stockée.

Étape 2 : créer le code Visual Basic

Le code Visual Basic suivant ouvre une connexion au serveur, crée une instruction préparée pour la procédure stockée, définit la taille du jeu de résultats sur 1 et ouvre le jeu de résultats en avant uniquement et en lecture seule. Lorsque vous exécutez ce code, tous les ID et noms de tous les auteurs s’affichent dans la fenêtre de débogage. Cet exemple de code utilise une connexion ODBC « sans DSN » pour que vous n’ayez pas besoin de configurer un nom de source de données (DSN) avec l’utilitaire d’administration ODBC.
  1. Commencer un nouveau projet dans Visual Basic. Form1 est créé par défaut.
  2. Ajoutez un bouton de commande (Command1) et un contrôle ListBox (list1) à Form1.
  3. Collez le code suivant dans la section déclarations générales de Form1 :
       Private Sub Command1_Click()     Dim cn As rdoConnection     Dim ps As rdoPreparedStatement     Dim rs As rdoResultset     Dim strConnect As String     strConnect = "driver={SQL Server};server=myserver;" & _       "database=pubs;uid=<username>;pwd=<strong password>"     rdoEnvironments(0).CursorDriver = rdUseOdbc     Set cn = rdoEnvironments(0).OpenConnection( _       dsName:="", _       Prompt:=rdDriverNoPrompt, _       ReadOnly:=False, _       Connect:=strConnect)     Set ps = cn.CreatePreparedStatement( _       Name:="ps1", _       SqlString:="{call TempTableTest }")     ps.RowsetSize = 1     Set rs = ps.OpenResultset( _       Type:=rdOpenForwardOnly, _       LockType:=rdConcurReadOnly)     While Not rs.EOF       list1.AddItem rs(0) & ", " & rs(1)       rs.MoveNext     Wend   End Sub
  4. Notez que vous devez modifier vos paramètres de base de données, d’UID et de mot de passe dans la méthode OpenConnection.
  5. Démarrez le programme ou appuyez sur la touche F5.
  6. Cliquez sur le bouton Command1 pour exécuter la procédure stockée et afficher les résultats dans le contrôle de liste.

Références


Pour obtenir une documentation complète, reportez-vous à la section «Microsoft ODBC 2,0
Guide de référence et SDK du programmeur.» Guide de Hitchhiker de Visual Basic et SQL Server, Microsoft Press. ISBN : 1-55615-906-4.).