Kann ich SMO von reinem T-SQL anrufen?

Question

Ich weiß, wie man eine gespeicherte Prozedur mit PowerShell und SMO skriptiert:

[System.reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") | out-null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.ConnectionInfo")  | out-null
$srv = New-Object "Microsoft.SqlServer.Management.Smo.Server" 
$srv.databases['MyDatabase'].StoredProcedures['MyProc'].TextBody

Aber da ich den Prozedurtext innerhalb einer Abfrage verwenden möchte, frage ich mich, ob ich SMO in irgendeiner Weise in reinem T-SQL anrufen kann.

Muss nur in der Entwicklungsumgebung laufen.

Übrigens: Eine Funktion, die die Definition eines gespeicherten Verfahrens mit einem gegebenen Namen zurückgibt, würde mein aktuelles Problem lösen, aber meine Frage nicht beantworten.

Bearbeiten:

Ich möchte herausfinden, welche Prozeduren auf eine bestimmte Tabelle verweisen, wenn ich diese Abfrage verwende:

SELECT p.name --, definition 
FROM sys.sql_modules m
join sys.objects p on m.object_id = p.object_id
where p.type = 'P'
and definition like '%SearchForThis%'

Das sind genau die gleichen Informationen, die ich mit SMO erhalten möchte.

Answer 1

Sie würden die verwenden sp_oa% gespeicherte Procs dafür. Oder CLR Seit SQL Server 2005.

Es kann nicht direkt über T-SQL durchgeführt werden, da T-SQL für die Datenmanipulation bestimmt ist. Sie müssen also eine der 2 oben genannten Methoden verwenden. Es sei denn, Sie möchten XP_CMDSHELL verwenden, um ein PowerShell -Skript auszuführen.

Dies bringt auch eine Einschränkung von T-SQL hervor: Wie kann man eine Objektdefinition auf die Festplatte erhalten? Und ich denke ein Grund, warum Sie das gefragt haben. Auch hier werden CLR oder SP_OA% es tun.

Eine Sache zu beachten ist das fast jeder Methode und Eigenschaft in SMO -Karten zu einem SQL -Befehl oder einer Abfrage. Die Verwendung von T-SQL zum Aufruf von SMO, das effektiv T-SQL ist, ist kreisförmig.

Und um die gespeicherte Prozedurdefinition zu erhalten, die Sie verwenden würden Object_Definition... Um die anderen in SMO verfügbaren Eigenschaften verfügbar zu machen, verwenden Sie Object_Property oder die Systemobjekte abfragen.

Answer 2

Wie es sich auf die Frage bezieht, wie angegeben (und nicht das Wunsch, wie in der "angegeben"Bearbeiten"):

Nein, es ist nicht möglich, SMO von T-SQL aufzurufen. Dies kann nicht über die von OLE Automation gespeicherten Verfahren (dh sp_OA*), noch über SQLCLR.

Oale Automatisierung

Ich bin mir nicht sicher, was die Olecomponent Name wäre, aber Sie können Objekte erstellen, indem Sie deren angeben Clsid. Natürlich ist es auch nicht einfach, das für SMO zu finden, aber ich habe zwei Referenzen im Inter-Webz gefunden:

1. Was ist die CLSID- und Prog -ID von microsoft.sqlserver.management.smo (auf Stapelüberlauf)
2. So erstellen.NET -Objekt aus dem einfachen jscript. (in der Stadt des Programmierers)

DECLARE @ObjectToken INT, @HResult INT;
DECLARE @Source VARCHAR(500), @Description VARCHAR(500);

EXEC @HResult = sp_OACreate '{603F0A84-5631-3CA0-BCE0-C96597C2C1A0}', @ObjectToken OUT;
--EXEC @HResult = sp_OACreate '{755F7A20-E39C-31E0-8174-2E430C2C4E7A}', @ObjectToken OUT;

IF (@HResult <> 0)
BEGIN
   EXEC sp_OAGetErrorInfo @ObjectToken, @Source OUT, @Description OUT;
   RAISERROR('OLE Automation error. HResult: %x; @Source: %s; @Description: %s',
             16, 1, @HResult, @Source, @Description);
   RETURN;
END;

EXEC sp_OADestroy @ObjectToken;

Beide Werte geben zurück:

MSG 50000, Stufe 16, Zustand 1, Zeile 14
OLE -Automatisierungsfehler. Hresult: 80040154; @Source: ODSole Extended -Verfahren; @Description: Klasse nicht registriert

Obwohl SMO gut sichtbar ist, vermute ich, dass es hier nicht mit der folgenden Anforderung zusammenhängt, was auf der MSDN-Seite für angegeben ist sp_oacreate

Das angegebene OLE -Objekt muss gültig sein und die unterstützen Idispatch Schnittstelle.

Die SMO -Bibliothek scheint das nicht zu implementieren IDispatch Schnittstelle.

Auch wenn es jemandem schafft, einen Weg zu finden, um dies zum Laufen zu bringen, ist dies immer noch schlecht beraten, wenn man bedenkt, dass die von OLE Automation gespeicherten Verfahren seit der Veröffentlichung von SQL Server 2005 veraltet sind.

SQLCLR

Während SQLCLR die natürliche Art und Weise zu sein scheint, mit SMO zu gehen (da SMO auch .NET ist), funktioniert dies definitiv nicht, da die SMO -Bibliothek ausdrücklich erkennt, ob sie auf dem SQL -Server verwendet wird, und wenn ja, fällt mit dem folgenden Fehler ab Botschaft:

MSG 6522, Stufe 16, Zustand 2, Zeile 1
Bei der Ausführung von benutzerdefinierten Routine oder aggregierten "Smotest" trat ein .NET-Framework-Fehler auf:
System.Exception: Diese Funktionalität ist in der SQLCLR deaktiviert. Es wird empfohlen, dass Sie aus Ihrer Kundenanwendung ausgeführt werden.
System.Exception:
unter microsoft.sqlserver.management.common.connectionManager..ctor ()
bei microsoft.sqlserver.management.smo.server..ctor ()

Das gibt es nicht (na ja, es sei denn, Sie sind Microsoft;).