Premiers pas avec SQL Server 7.0 (8)

Renvoi des résultats dans des procédures stockées
Il existe trois façons de renvoyer des résultats à partir de procédures stockées :
1. Renvoi d'ensembles de résultats
Il s'agit de la méthode la plus courante pour les applications clientes pour renvoyer des résultats. L'ensemble de résultats est généré en sélectionnant des données à l'aide de l'instruction SELECT. Les jeux de résultats peuvent être générés à partir de tables permanentes, de tables temporaires ou de variables locales. Renvoyer les résultats à une autre procédure stockée n’est pas une approche efficace. Une procédure stockée ne peut pas accéder à un jeu de résultats créé par une autre procédure stockée.
Par exemple, renvoyez un jeu de résultats à partir d'une table permanente :
USE pubs
GO
CREATE PROCEDURE ap_CreateResultFromPermtable
AS
SELECT au_iname FROM auteurs
GO
Par exemple , à partir d'une variable locale Créez un jeu de résultats :
USE pubs
GO
CREATE PROCEDURE ap_CreateResultFromVariable
AS
DECLARE @au_iname char(20)
SELECT @au_iname = au_iname FROM authors
WHERE au_id = '172-32-1176'
SELECT @au_id
GO
2 Définissez la valeur du paramètre OUTPUT
Les paramètres de sortie sont souvent utilisés pour récupérer les résultats des procédures stockées. Si un paramètre est défini comme OUTPUT lors du transfert vers une procédure stockée, toute modification apportée au paramètre restera en vigueur après la sortie du stockage.
Par exemple :
USE pubs
GO
CREATE PROCEDURE ap_SetOutputVar @count integer OUTPUT
AS
SELECT @count = count(*) FROM auteurs
GO
OUTPUT FROM Récupère la valeur du paramètre :
USE pubs
GO
CREATE PROCEDURE ap_GetOutputVar
AS
DECLARE @num integer
EXECUTE ap_SetOutputVar @num OUTPUT
PRINT « le décompte est " convert (char,@num)
GO
· Utilisez le curseur comme paramètre OUTPUT. Les curseurs peuvent utiliser les paramètres OUTPUT (sortie), mais ne peuvent pas être utilisés comme paramètres d'entrée. Autrement dit, le curseur peut être renvoyé en conséquence, mais il ne peut pas être transféré à la procédure. Lorsqu'un curseur est utilisé en paramètre, il doit être qualifié de SORTIE et VARYING. Le mot-clé VARYING indique que l'ensemble de résultats doit être utilisé pour prendre en charge les paramètres de sortie. Cela offre la possibilité de renvoyer un ensemble de résultats à la procédure appelante.
Par exemple :
USE pubs
GO
CREATE PROCEDURE GetTitleCount @count_cursor CURSOR VARYING OUTPUT
AS
SET @count_cursor = CURSOR
FOR
SELECT au_id,count( * )
FROM titleauthors
GROUP BY au_id
OPEN @count_cursor
GO
3. Retourner l'état via le paramètre RETURN
Il s'agit d'une méthode pour renvoyer un code d'erreur à partir d'une procédure stockée. Les procédures stockées renvoient toujours une valeur de statut et les utilisateurs peuvent également utiliser l'instruction RETURN pour renvoyer leur propre statut.
Par exemple :
USE pubs
GO
CREATE PROCEDURE ap_SetReturnStatus
AS
DECLARE @count integer
SELECT @count = count(*) FROM auteurs
IF @ count = 0
RETURN(1)
ELSE
RETURN (0)
GO
Par exemple, récupérez le statut renvoyé :
USE pubs
GO
CREATE PROCEDURE ap_GetReturnStatus
AS
DECLARE @status integer
EXECUTE @status = ap_SetReturnStatus
IF @status = 1
PRINT "Aucune ligne trouvée"
ELSE
PRINT "réussi"
GO

Gestion des erreurs dans les procédures stockées
Comme d'autres programmes, la gestion des erreurs dans les procédures stockées est très importante. Le changement de système @@error obtiendra une valeur après l'exécution de chaque instruction Transact SQL. Pour une exécution réussie, la valeur de @@error est 0. Si une erreur se produit, @@error contiendra des informations sur l'erreur. La variable système @@error est très importante pour la gestion des erreurs des procédures stockées.
Remarque : Afin d'éviter les erreurs, les valeurs​​qui peuvent être définies par @@error sont reflétées dans l'"erreur" de la table sysmessages.
Il existe deux types d'erreurs dans les procédures stockées :
1. Erreurs liées à la base de données
Ces erreurs sont causées par des incohérences dans la base de données. Le système utilise une valeur @@error non nulle pour représenter une erreur spécifique. question de base de données. Une fois Transact SQL exécuté, l'erreur survenue peut être obtenue via @@error. Si @@error s'avère différent de zéro, les mesures nécessaires doivent être prises et, dans la plupart des cas, le magasin reviendra sans autre traitement. L'exemple suivant montre une méthode typique pour obtenir des erreurs de base de données. Cette procédure place le code d'erreur dans une variable de sortie afin que le programme appelant puisse y accéder.
USE pubs
GO
CREATE PROCEDURE ap_TrapDatabaseError @return_code integer OUTPUT
AS
UPDATE auteurs SET au_iname = « Jackson »
WHERE au_iname = « Smith »
IF @@error <> 0
BEGIN
​​​​SELECT @return_code = @@error
RETOUR
END
ELSE
@return_code = 0
GO
2. erreur logique
Ces erreurs sont causées par des violations de règles métier. Pour obtenir ces erreurs, vous devez d'abord définir des règles métier. Sur la base de ces règles, vous devez ajouter le code de détection d'erreur nécessaire à la procédure stockée. Les gens utilisent souvent l'instruction RAISERROR pour signaler ces erreurs. RAISERROR offre la possibilité de renvoyer des erreurs définies par l'utilisateur et de définir la variable @@error sur un numéro d'erreur défini par l'utilisateur. Les messages d'erreur peuvent être créés dynamiquement ou récupérés à partir de la table "sysmessages" en fonction du numéro d'erreur. Lorsqu'une erreur se produit, elle est renvoyée au client sous forme de message d'erreur du serveur. Voici la syntaxe de la commande RAISERROR :
RAISERROR (msg_id | msg_str, gravité, état
[, argument ][,…n]])
[AVEC options]
Msg_id spécifie l'identifiant du message défini par l'utilisateur, le message est stocké dans la table système "sysmessages".
Msg_str est la chaîne de message utilisée pour créer dynamiquement des messages. Ceci est très similaire à "printf" en langage C.
Gravité définit la gravité du message d'erreur attribué par l'utilisateur.
L'état est une valeur entière comprise entre 1 et 127, qui représente des informations incorrectes sur l'état de l'appel. Les valeurs d'état négatives seront par défaut 1.
OPTIONS indique des options de personnalisation incorrectes. Les valeurs valides d'OPTIONS sont les suivantes :
1) LOG.
Consigne les erreurs dans le journal des erreurs du serveur et dans le journal des événements NT. Cette option nécessite des messages avec une gravité comprise entre 19 et 25. Seuls les administrateurs système peuvent émettre de tels messages.
2) ATTENDEZ MAINTENANT.
Envoyer immédiatement le message au serveur client.
3) SETERREUR.
Définissez la valeur de @@error sur msg_id ou 5000 quel que soit son niveau de gravité.

Appel de procédure à distance
SQL Server offre la possibilité d'appeler des procédures stockées qui résident sur différents serveurs. L’appel d’une telle procédure stockée est appelé appel de procédure stockée distante. Pour que les appels soient transférés d'un serveur SQL à un autre, les deux serveurs doivent être définis comme des serveurs distants efficaces l'un pour l'autre.
Définissez la configuration du serveur distant :
· Développez le groupe d'un certain serveur.
· Faites un clic droit sur le serveur et cliquez sur "Propriétés".
· Définissez l'option "Autoriser les autres serveurs SQL à se connecter à distance à ce serveur SQL via RPC".
· Définissez la valeur de l'option "Query time out", qui spécifie le nombre de secondes d'attente pour un retour d'un traitement de requête. La valeur par défaut est 0, ce qui signifie qu'un temps d'attente illimité est autorisé.
· Après avoir défini les options de configuration, cliquez sur "OK".
· Après le redémarrage du serveur, les modifications prendront effet.
· Répétez les mêmes étapes sur l'autre serveur distant.
Pour appeler une procédure stockée distante, vous devez spécifier le nom du serveur, suivi du nom de la base de données et du nom du propriétaire. Vous trouverez ci-dessous un exemple d'appel d'une procédure stockée sur un autre serveur (Serveur2).
Exec server2.pubs.dbo.myproc

Remarques de Doudou :
Ceci n'est qu'une introduction superficielle aux connaissances communes de SQL Server. Il est également destiné aux programmeurs qui écrivent des applications basées sur SQL Server. bases de données, pas le gestionnaire de base de données. Mais pour les programmeurs d’applications, comprendre la gestion des bases de données est également très utile. Il est recommandé de vous familiariser à l'avenir avec la gestion de bases de données par vous-même, ce qui est également très utile pour optimiser les programmes.

Ce qui précède est le contenu de Démarrer avec SQL Server 7.0 (8). Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !

————————Texte intégral——————————