article de presse - Cap Data Consulting

P ratique
Vous remarquerez la détection de la valeur nulle du paramètre à l'aide
de la propriété IsNull de celui-ci, et l'utilisation de l'objet
WindowsIdentity dans SqlContext pour retourner le nom du login
connecté (l'équivalent de la fonction T-SQL system_user).
Quelques notes
Comme avec une procédure stockée T-SQL, vous pouvez attribuer une valeur
de retour en définissant votre méthode comme retournant un SqlInt32 (ou
un System.Int32, ce qui entraînera une conversion implicite) à la place du
void. Il vous suffira d'indiquer votre valeur de retour par un return.
Pour définir un paramètre OUTPUT, passez votre paramètre par référence.
En C#, ajoutez le mot-clé ref devant la déclaration de votre paramètre.
Vous devez également utiliser le mot-clé OUTPUT dans la déclaration
de votre paramètre dans le CREATE PROCEDURE.
Comme vous ne pouvez pas définir de valeur par défaut aux paramètres
des fonctions C#, les valeurs par défaut des paramètres se définissent
au CREATE PROCEDURE. Ce mécanisme vous permet d'ailleurs de créer
plusieurs procédures au nom différent appelant le même code .NET,
avec des valeurs par défaut différentes.
Vous pouvez créer de toute pièce des resultsets dans votre code, à l'aide
des objets et méthodes suivants :
SqlMetaData Définir les colonnes de votre table et leur
type de données
SqlDataRecord Créer des enregistrements, en passant un
tableau de SqlMetaData au constructeur
Pipe.SendResultsStart Commencer l'envoi du resultset au client
(SqlDataRecord)
Pipe.SendResultsRow Envoyer un SqlDataRecord
(SqlDataRecord)
Pipe.SendResultsEnd() Terminer l'envoi du resultset
Transactions
Pour gérer l'éventuelle transaction dans laquelle votre procédure stockée
peut s'exécuter, vous avez à votre disposition l'objet Transaction du
namespace System.Transactions (dans System.Transactions.dll), qui est
une nouveauté du framework 2.0. L'intégration entre cet objet
Transaction et les transactions SQL Server est très étroite. Lorsque du
code .NET est exécuté dans le contexte du SQLCLR, l'objet
System.Transactions.Transaction.Current reçoit le contexte de transaction.
Si celui-ci est non nul, cela veut dire qu'une transaction est en cours.
Tout code SQL exécuté dans la connexion de contexte, et même dans une
autre connexion au serveur, est enlisté dans la transaction. En fait, Cet
objet est capable de convertir automatiquement la transaction locale en
une transaction distribuée lorsqu'une connexion est ouverte vers un
autre serveur via ADO.NET, ce qui la rend particulièrement puissante et
permet de gérer les transactions distribuées avec un codage minimal.
Déploiement
Lorsque votre procédure est créée, il vous reste à l'intégrer dans SQL
Server. Le déploiement intégré de Visual Studio 2005 (clic droit sur le
projet dans l'explorateur de solutions, deploy), va prendre toute la pro-
Programmez n°85 68 avril 2006
cédure en charge : copie sur le serveur, remplacement d'une éventuelle
version existante, enregistrement de l'assemblage et de la procédure.
-- Enregistrement l'assemblage
CREATE ASSEMBLY GetSessions FROM 'c:\temp\Programmez.dll'
WITH PERMISSION_SET=SAFE
GO
-- Enregistrer la procédure
CREATE PROCEDURE GetSessions @user varchar(255) AS
EXTERNAL NAME [Programmez].[StoredProcedures].[GetSessions]
Vous pouvez recharger la procédure avec un ALTER, seulement si vous n'avez
pas modifié son interface publique, c'est-à-dire la signature de la méthode.
ALTER ASSEMBLY GetSessions FROM 'c:\temp\Programmez.dll'
Ajouter une assembly
Après déploiement, votre procédure pourra être appelée depuis SQL
Server à l'aide d'une commande semblable à :
exec dbo.GetSessions @user =
'mondomaine\moi' –- en cas de connexion intégrée Windows
Un conseil : vérifiez, par exemple à l'aide d'une trace, ce que fait l'outil de
déploiement de Visual Studio. Vous pouvez préférer un déploiement
manuel, par exemple pour ajuster le nom et la taille de vos paramètres, ou
leur attribuer une valeur par défaut. Notez que vous pouvez très bien déclarer
plusieurs fois le même assemblage avec des noms différents et des
paramètres par défaut différents si vous le souhaitez.
Si vous voulez vérifier les performances d'exécution, vous verrez passer
votre procédure stockée dans le profiler de SQL Server, avec son temps CPU
et les indicateurs habituels, comme si c'était une procédure Transact SQL.
Nous avons vu brièvement comment créer des procédures stockées.
Sachez que de la même façon, vous pouvez créer des fonctions, des
déclencheurs, et des types de données personnalisés dans un langage
du MSIL, ce qui ouvre tout un nouveau champ de perspectives.
■ Rudi Bruchez rudi@babaluga.com
(MCDBA) : http://www.babaluga.com/
Niveau
SGDB facile avancé expert