46

Where can I find information about stored procedure parameters? In my situation I need to know only the input parameters of given store procedure.

In the sys.objects there is only common details about the procedure. In sys.sql_modules I can extract the whole SQL text of a procedure.

As (in SQL Server Management studio) I am able to extract information about the parameters in tabular view using ALT+F1 when selecting the procedure name. I hope there is some place from which I can extract input parameters details in that way.

gotqn
  • 42,737
  • 46
  • 157
  • 243

11 Answers11

93
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')
Raj
  • 10,653
  • 2
  • 45
  • 52
  • 4
    You should just use `sys.parameters` unless you really need parameters for system procedures as well, and you should of course use the schema name in the object_id call as well. – Aaron Bertrand Nov 21 '13 at 08:47
  • I've noticed this gives me an "extra" parameter with parameter_id = 0, and a blank parameter name. The object I used was an scalar function. This behavior only happens with scalar functions. I think it's the "returns" value. Maybe you use add parameter_id > 0 to the where. I mean, on sp's it works perfectly, but gives you an unexpected param if you use a scalar function. – soulblazer Mar 31 '17 at 20:49
  • 3
    Is there a way to find out whether the parameter is optional, that is, it has a default value? I find that `has_default_value` is always zero. (MSSQL 2008R2) – Ed Avis May 05 '17 at 07:40
  • SQL Server only maintains default values for CLR objects in this catalog view; therefore, this column has a value of 0 for Transact-SQL objects. – Raj May 05 '17 at 08:04
  • @AaronBertrand why should we use sys.parameters instead? – reggaeguitar May 07 '18 at 19:51
  • 1
    @reggaeguitar Instead of sys.all_parameters? Because sys.parameters just lists parameters for the objects you have created in your database. The system version of the view has 7,000+ rows that are going to be identical in every database, so their value is pretty much near zero (again, unless you actually need parameters for built-in system objects). – Aaron Bertrand May 08 '18 at 00:17
  • @EdAvis **SQL Server only maintains default values for CLR objects **in this catalog view; therefore, this column has a value of 0 for Transact-SQL objects. To view the default value of a parameter in a Transact-SQL object, query the definition column of the sys.sql_modules catalog view, or use the OBJECT_DEFINITION system function. Refer to link here [link] (https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-parameters-transact-sql?view=sql-server-2017) – Nilesh Aug 29 '19 at 04:33
12
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'
Ahmad Behjati
  • 536
  • 6
  • 4
3

For a supplied procedure name, the following query lists all of its parameters and their order along with their type and the type's length (for use with VARCHAR, etc.)

Replace procedure_name with the name of your procedure.

DECLARE @ProcedureName VARCHAR(MAX) = 'procedure_name'

SELECT
    pa.parameter_id AS [order]
    , pa.name AS [name]
    , UPPER(t.name) AS [type]
    , 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
WonderWorker
  • 8,539
  • 4
  • 63
  • 74
  • 1
    This method almost worked perfectly, except what is returned for t.is_nullable is always true regardless of whether the parameter accepts nulls or not. (Tested on Sql Server 2014 and 2017) Any suggestions? – JRodd Aug 29 '19 at 20:39
  • 1
    Interesting. t.is_nullable seems to return 0 if READONLY is applied to the parameter. There is a pa.is_nullable and pa.has_default_value available, but they either don't appear to work or I just don't understand them. I will remove the t.is_nullable line. – WonderWorker Sep 02 '19 at 14:13
1

There are the system tables, like sys.objects or sys.sysobjects.

Or you could also look at INFORMATION_SCHEMA, specifically INFORMATION_SCHEMA.ROUTINES and INFORMATION_SCHEMA.ROUTINE_COLUMNS.

Because it is in the ANSI-standard INFORMATION_SCHEMA, there are less SQL Server specific quirks. IMHO it is easier to understand for most things.

Paul Draper
  • 78,542
  • 46
  • 206
  • 285
  • 1
    There is no way to get the procedure parameters details from this table. The only fields that include them are fields including the whole text of the SQL procedure. I need to get information like this `[ParameterName][ParameterTyp]` – gotqn Nov 21 '13 at 08:42
  • 5
    You haven't explained at all where to get the parameters, and I think you'll get [a lot of debate about `INFORMATION_SCHEMA`](https://sqlblog.org/blogs/aaron_bertrand/archive/2011/11/03/the-case-against-information-schema-views.aspx) - mostly because they're incomplete and relatively useless for a lot of tasks. – Aaron Bertrand Nov 21 '13 at 08:48
  • 1
    @AaronBertrand, useless for some tasks, but not for this one. – Paul Draper Nov 21 '13 at 08:52
  • 5
    @Paul so you advocate being inconsistent, and use INFORMATION_SCHEMA when it's useful, and catalog views when it's not? Where are you going to keep track of when you should avoid INFORMATION_SCHEMA because it's incomplete? Why not use the actual catalog views that are complete, all the time, instead of playing this conditional switch-a-roo? – Aaron Bertrand Nov 21 '13 at 08:53
  • On MSSQL 2008R2 I find that `information_schema.routine_columns` has rows for user-defined functions, but not user-defined procedures. By contrast `sys.parameters` does include procedures. – Ed Avis May 05 '17 at 07:20
  • Given `create function dbo.udf_test (@a int = 5) returns int as begin return @a end` on MSSQL 2008R2 I find it doesn't appear in `information_schema.routine_columns` at all, although other user-defined functions do appear. – Ed Avis May 05 '17 at 07:28
  • 1
    @AaronBertrand, on the contrary. INFORMATION_SCHEMA is ANSI standard (e.g. SQL Server, Oracle, MySQL, PostreSQL). Catalog views, on the other hand, are far more inconsistent across DMBS's. – Paul Draper May 05 '17 at 22:57
  • INFORMATION_SCHEMA.ROUTINES for long definitions in ROUTINE_DEFINITION cuts stuff off so it probably should be aliased to ROUTINE_DEFINTIION_FIRST8000 – Mark Schultheiss May 29 '18 at 12:21
1

The following Query worked for me:

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

For more specific result with parameter order:

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;
Naveen Kumar V
  • 2,559
  • 2
  • 29
  • 43
1
SELECT *  
FROM INFORMATION_SCHEMA.PARAMETERS 
WHERE SPECIFIC_NAME='proc_name' 
ORDER BY ORDINAL_POSITION 

(tested with MSSQL 2014)

El.Hum
  • 1,479
  • 3
  • 14
  • 23
1

It Contains a row for each parameter of an object that accepts parameters. If the object is a scalar function, there is also a single row describing the return value. That row will have a parameter_id value of 0.

SELECT *  
FROM sys.parameters  
WHERE object_id = object_id('SchemaName.ProcedureName')

Reference: https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-parameters-transact-sql?view=sql-server-2017

Santhana
  • 407
  • 4
  • 16
1

Probably a little late , but since the search term Get parameters for all stored procedure on SQL on google, landed me this page, I will post that solution (which is also bit different from other answers in terms of join)

 Select PROCS.name As StoredProcName,TYPE_NAME(user_type_id) As ParameterType,PARAMS.name As Params from sys.procedures PROCS
JOIN sys.parameters PARAMS WITH(NOLOCK) ON PROCS.object_id = PARAMS.object_id
Order by PROCS.object_id
Simsons
  • 12,295
  • 42
  • 153
  • 269
1

Information Schemas are are ISO standard SQL. The PARAMETERS information schema view displays a list of parameters for user-defined functions and stored procedures in the current or specified database. This is one I use to get a list of all parameters for all procedures:

SELECT          SPECIFIC_NAME,  PARAMETER_MODE, PARAMETER_NAME, DATA_TYPE 
FROM            INFORMATION_SCHEMA.PARAMETERS
ORDER BY        SPECIFIC_NAME
Neve
  • 367
  • 2
  • 9
0

An extension of Raj's answer above

;WITH CTE
 AS (SELECT OBJECT_NAME(OBJECT_ID) AS  sql_module_name
           ,CASE
                WHEN OBJECTPROPERTY(OBJECT_ID,'IsProcedure') = 1 THEN 'Stored Procedure'
                WHEN OBJECTPROPERTY(OBJECT_ID,'IsScalarFunction') = 1 THEN 'Scalar Function'
                WHEN OBJECTPROPERTY(OBJECT_ID,'IsTableFunction') = 1 THEN 'Table Function'
            END AS                     sql_module_type
           ,parameter_id AS            parameter_order
           ,name AS                    parameter_name
           ,is_nullable AS             parameter_is_nullable_flag
           ,is_output AS               parameter_is_output_flag
           ,TYPE_NAME(user_type_id) AS parameter_type
           ,max_length AS              parameter_length
           ,CASE
                WHEN TYPE_NAME(system_type_id) = 'uniqueidentifier' THEN precision
                ELSE OdbcPrec
                     (system_type_id,max_length,precision
                     )
            END AS                     parameter_precision
           ,OdbcScale
            (system_type_id,scale
            ) AS                       parameter_scale
     FROM   sys.parameters)
 SELECT DENSE_RANK() OVER(
        ORDER BY sql_module_type
                ,sql_module_name ASC) AS group_id
       ,sql_module_name
       ,sql_module_type
       ,parameter_order
       ,parameter_name
       ,parameter_is_nullable_flag
       ,parameter_is_output_flag
       ,parameter_type
       ,parameter_length
       ,parameter_precision
       ,parameter_scale
 FROM   CTE
 ORDER BY sql_module_type
         ,sql_module_name
         ,parameter_order;
AeyJey
  • 2,111
  • 2
  • 14
  • 21
-3
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]
  • 5
    There is absolutely no reason to use deprecated, backward compatibility views for this information on any system SQL Server 2005 and up (which the OP's must be, since they mentioned `sys.objects` and `sys.sql_modules`). This would be fine for a legacy SQL Server 2000 question, but not for anything modern. – Aaron Bertrand Nov 21 '13 at 09:04