Comment obtenir les paramètres de procédure stockée détails?

Où puis-je trouver des informations sur les paramètres de procédure stockée? Dans ma situation, j'ai besoin de savoir que les paramètres d'entrée de la boutique de la procédure.

Dans le sys.objects il est seulement commun de détails sur la procédure. Dans sys.sql_modules je peux extraire l'ensemble du texte de SQL d'une procédure.

(Dans SQL Server Management studio), je suis capable d'extraire des informations sur les paramètres de l'affichage sous forme de tableau à l'aide de ALT+F1 lors de la sélection du nom de la procédure. J'espère qu'il y a de la place à partir de laquelle je peux extraire des paramètres d'entrée des détails de cette façon.

Conformément à ma connaissance, je ne pense pas que n'importe quelle table de magasins de paramètres de procédure stockée, corrigez-moi si je me trompe.
oui, vous avez tort.

OriginalL'auteur gotqn | 2013-11-21

55
```
select  
   'Parameter_name' = name,  
   'Type'   = type_name(user_type_id),  
   'Length'   = max_length,  
   'Prec'   = case when type_name(system_type_id) = 'uniqueidentifier' 
              then precision  
              else OdbcPrec(system_type_id, max_length, precision) end,  
   'Scale'   = OdbcScale(system_type_id, scale),  
   'Param_order'  = parameter_id,  
   'Collation'   = convert(sysname, 
                   case when system_type_id in (35, 99, 167, 175, 231, 239)  
                   then ServerProperty('collation') end)  

  from sys.parameters where object_id = object_id('MySchema.MyProcedure')
```
Vous devriez utiliser sys.parameters à moins que vous vraiment besoin de paramètres pour les procédures du système en tant que bien, et vous devez utiliser le nom du schéma dans le object_id appeler ainsi.
J'ai remarqué que cela me donne un "extra" paramètre avec parameter_id = 0, et une vierge du nom du paramètre. L'objet que j'ai utilisé était une fonction scalaire. Ce problème se produit uniquement avec les fonctions scalaires. Je pense que c'est le "retour" de la valeur. Peut-être que vous utilisez un parameter_id > 0 pour le cas où. Je veux dire, sur sp, il fonctionne parfaitement, mais vous donne une inattendue param si vous utilisez une fonction scalaire.
Est-il un moyen de savoir si le paramètre est optionnel, qui est, il a une valeur par défaut? Je trouve que has_default_value est toujours à zéro. (MSSQL 2008R2)
SQL Server ne maintient les valeurs par défaut pour les objets CLR dans ce catalogue; par conséquent, cette colonne a une valeur de 0 pour les instructions Transact-SQL objets.
Au lieu de sys.all_parameters? Parce que sys.les paramètres de listes de paramètres pour les objets que vous avez créé dans votre base de données. La version du système du point de vue a de 7 000+ lignes qui vont être identique dans chaque base de données, de sorte que leur valeur est très proche de zéro (de nouveau, sauf si vous avez réellement besoin de paramètres intégrés dans le système des objets).

OriginalL'auteur Raj

select * from sys.parameters 
inner join sys.procedures on parameters.object_id = procedures.object_id 
inner join sys.types on parameters.system_type_id = types.system_type_id AND parameters.user_type_id = types.user_type_id
where procedures.name = 'sp_name'

OriginalL'auteur Ahmad Behjati

1

Il y a les tables système, comme sys.objects ou sys.sysobjects.

Ou vous pouvez aussi les regarder INFORMATION_SCHEMA, spécifiquement INFORMATION_SCHEMA.ROUTINES et INFORMATION_SCHEMA.ROUTINE_COLUMNS.

Parce que c'est dans la norme ANSI -INFORMATION_SCHEMA, il y a de moins en moins spécifique à SQL Server bizarreries. À mon humble avis il est plus facile à comprendre pour la plupart des choses.

Il n'y a aucun moyen d'obtenir les paramètres de la procédure détails de ce tableau. Les seuls champs qui comprennent entre eux sont les champs, y compris le texte intégral de la procédure SQL. J'ai besoin d'obtenir des informations de ce type [ParameterName][ParameterTyp]
Vous n'avez pas expliqué du tout où obtenir les paramètres, et je pense que vous aurez beaucoup de débat sur INFORMATION_SCHEMA - surtout parce qu'ils sont incomplets et relativement inutile pour beaucoup de tâches.
inutile pour certaines tâches, mais pas pour celui-ci.
afin de vous défendre d'être incompatibles, et l'utilisation INFORMATION_SCHEMA lorsque c'est utile, et le catalogue de vues lorsqu'il ne l'est pas? Où allez-vous garder une trace de quand vous devriez éviter de INFORMATION_SCHEMA parce qu'elle est incomplète? Pourquoi ne pas utiliser le catalogue des vues qui sont complètes, tout le temps, au lieu de jouer à ce conditionnelle switch-a-roo?
au contraire. INFORMATION_SCHEMA est conforme à la norme ANSI (par exemple, SQL Server, Oracle, MySQL, PostreSQL). Catalogue de vues, d'autre part, sont beaucoup plus inégal entre DMBS.

OriginalL'auteur Paul Draper

Fournis nom de la procédure, la requête ci-dessous la liste de toutes ses paramètres et leur ordre ainsi que leur type, si le type est nullable et le type de la longueur (pour une utilisation avec VARCHAR, etc.)

Remplacer procedure_name avec le nom de votre procédure.

DECLARE @ProcedureName VARCHAR(MAX) = 'procedure_name'

SELECT
    pa.parameter_id AS [order]
    , pa.name AS [name]
    , UPPER(t.name) AS [type]
    , t.is_nullable AS [nullable] 
    , t.max_length AS [length] 
FROM 
    sys.parameters AS pa 
    INNER JOIN sys.procedures AS p on pa.object_id = p.object_id 
    INNER JOIN sys.types AS t on pa.system_type_id = t.system_type_id AND pa.user_type_id = t.user_type_id
WHERE 
    p.name = @ProcedureName
ORDER BY 
    t.is_nullable DESC

OriginalL'auteur Knickerless-Noggins

1

Il Contient une ligne pour chaque paramètre d'un objet qui accepte des paramètres. Si l'objet est une fonction scalaire, il y a aussi une ligne unique décrivant la valeur de retour. Cette ligne aura un parameter_id valeur de 0.
```
SELECT *  
FROM sys.parameters  
WHERE object_id = object_id('SchemaName.ProcedureName')
```
Référence: https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-parameters-transact-sql?view=sql-server-2017

s'il vous plaît ajouter quelques explications pour votre réponse
Merci pour votre giudance. @El.Jambon..

OriginalL'auteur Santhana

La Requête suivante a fonctionné pour moi:

SELECT * FROM sys.parameters sp1, sys.procedures sp2 WHERE sp1.object_id = sp2.object_id

Pour plus de résultat avec le paramètre de commande:

SELECT * FROM sys.parameters sp1, sys.procedures sp2, sys.types st WHERE sp1.object_id = sp2.object_id AND sp2.name = 'usp_nameofstoredprocedure' AND sp1.user_type_id = st.user_type_id ORDER BY sp1.parameter_id asc;

Il fonctionne très bien avec MSSQL Server version 11.0.3***).

OriginalL'auteur Naveen Kumar V

SELECT *  
FROM INFORMATION_SCHEMA.PARAMETERS 
WHERE SPECIFIC_NAME='proc_name' 
ORDER BY ORDINAL_POSITION

(testé avec MSSQL 2014)

OriginalL'auteur bertrand gajac

-2
```
select t1.[name] as [SP_name],t2.[name] as [Parameter_name],
t3.[name] as [Type],t2.[Length],t2.colorder as [Param_order]
from sysobjects t1
inner join syscolumns t2 on t1.[id]=t2.[id]
inner join systypes t3 on t2.xtype=t3.xtype
where t1.[name]='My_StoredProc_Name'
order by [Param_order]
```
Il n'y a absolument aucune raison d'utiliser obsolète, compatibilité descendante vues pour cette information sur le système de SQL Server 2005 et jusqu' (qui l'OP doit être, depuis qu'ils ont mentionnés sys.objects et sys.sql_modules). Ce serait bien pour un héritage SQL Server 2000 question, mais pas pour quelque chose de moderne.

OriginalL'auteur user3004228

Vous devez vous connecter pour publier un commentaire.