Pobrać nazwy kolumn i typy procedury składowanej?

[Właśnie zdałem sobie sprawę, że już wcześniej odpowiedziałem na to pytanie]

W przypadku procedury składowanej jest to o wiele bardziej skomplikowane niż w przypadku widoku lub tabeli. Jednym z problemów jest to, że procedura składowana może mieć wiele różnych ścieżek kodu w zależności od parametrów wejściowych, a nawet rzeczy, których nie możesz kontrolować, takich jak stan serwera, pora dnia itp. Na przykład to, czego można oczekiwać jako wynik ta procedura składowana? Co się stanie, jeśli istnieje wiele zestawów wyników niezależnie od warunków warunkowych?

CREATE PROCEDURE dbo.foo
  @bar INT
AS
BEGIN
  SET NOCOUNT ON;

  IF @bar = 1
    SELECT a, b, c FROM dbo.blat;
  ELSE
    SELECT d, e, f, g, h FROM dbo.splunge;
END
GO

Jeśli twoja procedura składowana nie ma ścieżek kodu i masz pewność, że zawsze zobaczysz ten sam zestaw wyników (i możesz z góry określić, jakie wartości należy podać, jeśli procedura składowana ma parametry nieopcjonalne), weźmy prosty przykład:

CREATE PROCEDURE dbo.bar
AS
BEGIN
  SET NOCOUNT ON;

  SELECT a = 'a', b = 1, c = GETDATE();
END
GO

FMTONLY

Jednym ze sposobów jest zrobienie czegoś takiego:

SET FMTONLY ON;
GO
EXEC dbo.bar;

To da ci pusty zestaw wyników, a aplikacja kliencka może przyjrzeć się właściwościom tego zestawu wyników, aby określić nazwy kolumn i typy danych.

Teraz jest wiele problemów z SET FMTONLY ON; że nie będę tutaj wchodził, ale przynajmniej należy zauważyć, że to polecenie jest przestarzałe - nie bez powodu. Uważaj także, aby SET FMTONLY OFF; kiedy skończysz, lub będziesz się zastanawiać, dlaczego pomyślnie utworzyłeś procedurę składowaną, ale potem nie możesz jej wykonać. I nie, nie ostrzegam przed tym, bo mi się to właśnie przydarzyło. Szczery. :-)

OPENQUERY

Tworząc połączony serwer sprzężenia zwrotnego, możesz użyć narzędzi takich jak OPENQUERY aby wykonać procedurę składowaną, ale zwrócić zestaw wyników, który można komponować (cóż, zaakceptuj to jako bardzo luźną definicję), który możesz sprawdzić. Najpierw utwórz serwer pętli zwrotnej (zakłada to lokalną instancję o nazwie FOO ):

USE master;
GO
EXEC sp_addlinkedserver @server = N'.\FOO', @srvproduct=N'SQL Server'
GO
EXEC sp_serveroption @server=N'.\FOO', @optname=N'data access', 
  @optvalue=N'true';

Teraz możemy wykonać powyższą procedurę i wprowadzić ją do zapytania w ten sposób:

SELECT * INTO #t 
FROM OPENQUERY([.\FOO], 'EXEC dbname.dbo.bar;')
WHERE 1 = 0;

SELECT c.name, t.name
FROM tempdb.sys.columns AS c
INNER JOIN sys.types AS t
ON c.system_type_id = t.system_type_id
WHERE c.[object_id] = OBJECT_ID('tempdb..#t');

To ignoruje typy aliasów (wcześniej znane jako typy danych zdefiniowane przez użytkownika), a także może wyświetlać dwa wiersze dla kolumn zdefiniowanych jako na przykład sysname . Ale z powyższego daje:

name   name
----   --------
b      int
c      datetime
a      varchar

Oczywiście jest tu więcej pracy do zrobienia - varchar nie pokazuje długości i będziesz musiał uzyskać precyzję / skalę dla innych typów, takich jak datetime2 , time i decimal . Ale to dopiero początek.

Serwer SQL 2012

W SQL Server 2012 wprowadzono kilka nowych funkcji, które znacznie ułatwiają odnajdywanie metadanych. Dla powyższej procedury możemy wykonać następujące czynności:

SELECT name, system_type_name
FROM sys.dm_exec_describe_first_result_set_for_object
(
  OBJECT_ID('dbo.bar'), 
  NULL
);

Między innymi zapewnia to nam precyzję i skalę oraz rozwiązuje typy aliasów. Dla powyższej procedury daje to:

name   system_type_name
----   ----------------
a      varchar(1)
b      int
c      datetime

Wizualnie nie ma dużej różnicy, ale kiedy zaczniesz zagłębiać się w różne typy danych z różną precyzją i skalą, docenisz dodatkową pracę, jaką ta funkcja wykonuje dla Ciebie.

Wada:w SQL Server 2012 przynajmniej te funkcje działają tylko w pierwszej zestaw wyników (jak sugeruje nazwa funkcji).