Ich schrieb eine einfache UDF, die eine Grafik plotten und auf der Festplatte speichern sollte. Tatsächlich benutze ich eine UDF als Proxy zwischen SQL SERVER und R, also übergibt UDF das R-Skript nur über DCOM von SQL SERVER an die R-Engine. Alles funktioniert gut, bis ich versuche, eine Grafik zu plotten oder auf der Festplatte zu speichern. Ich habe die Assembly mit UNSAFE-Berechtigungen erstellt.
Also, es geht so: SQL Engine - & gt; UDF - & gt; (D) COM-SERVER - & gt; R - & gt; (D) COM-SERVER - & gt; UDF - & gt; SQL Engine.
Also, mein erstes Problem ist, kann ich GUI von einem UDF erstellen? Ich denke nicht, aber es lohnt sich zu fragen.
Das zweite Problem ist, warum eine Assembly mit UNSAFE-Berechtigung nicht auf das Dateisystem zugreifen kann. Ich erhalte keinen Fehler, es passiert einfach nichts.
Die R-Umgebung befindet sich in dem unterschiedlichen Adressraum, daher sehe ich keine Gründe, warum die Berechtigungen von SQL Engine für CLRs dies beeinflussen würden.
Danke
Bearbeiten:
Ich habe versucht, dasselbe mit Prozeduren zu machen. Jetzt wird eine leere Datei erstellt. Das ist mein R-Testcode:
%Vor%Irgendeine Idee, was hier passiert?
Aber es ist nicht klar, warum Sie die Dinge so machen. Es wäre wahrscheinlich viel einfacher, ein kleines (?) Programm außerhalb von SQL Server zu schreiben, um die Daten aus der Datenbank zu erhalten, Ihr R-Programm aufzurufen und das Image zu speichern. Der serverseitige Code in SQL Server eignet sich hervorragend für die Verarbeitung von Daten, ist jedoch sehr umständlich für die Interaktion mit Dateisystemen und externen Ressourcen im Allgemeinen, selbst wenn Sie CLR-Code verwenden.
Gibt es einen bestimmten Grund, warum Sie dies in SQL Server tun müssen?
Um auf das Dateisystem zuzugreifen, ist es besser, SSIS zu verwenden. Sie können das Paket jederzeit bearbeiten und testen und die Protokollierung bei Bedarf vornehmen. Sie können diesem Paket auch eine grafische Benutzeroberfläche in VisualStudio hinzufügen. Der Zugriff auf das Dateisystem von DatabaseEngine ist aufgrund möglicher Sicherheitsprobleme nicht empfehlenswert.
Mein erstes Problem ist, kann ich GUI von einem UDF erstellen?
Sie können System.Drawing zum Erstellen und / oder Bearbeiten von Bildern verwenden, aber:
PERMISSION_SET von UNSAFE und System.Drawing in SQL Server als UNSAFE
Das zweite Problem ist, warum eine Assembly mit UNSAFE-Berechtigung nicht auf das Dateisystem zugreifen kann. Ich erhalte keinen Fehler, nur passiert nichts.
Eine Assembly, die als EXTERNAL_ACCESS oder UNSAFE markiert ist, kann auf externe Ressourcen zugreifen. Wenn Sie dies versuchen und keine Fehlermeldung erhalten, wird dies angezeigt. Es ist jedoch unklar, was "nichts passiert" bedeutet, weil entweder Sie einen catch -Block haben, der den Fehler "verschluckt", oder die Datei in einem Verzeichnis erstellt wurde, das Sie nicht erwartet haben, weil Sie einen relativen Pfad anstelle von verwendet haben ein absoluter Pfad.
Zwei Probleme (obwohl sie miteinander verknüpft sind) mit Zugriff auf externe Ressourcen sind:
Welche Windows / Active Directory-Anmeldung wird für diesen Zugriff verwendet? Standardmäßig greift SQLCLR (genau wie xp_cmdshell ) auf das System im Sicherheitskontext des Kontos "Anmelden als" für den Prozess MSSQLSERVER zu. Oder Sie haben die Möglichkeit, den Identitätswechsel zu aktivieren, der den Sicherheitskontext desjenigen Benutzers annimmt, der den SQLCLR-Code ausgeführt hat, vorausgesetzt, dass die Anmeldung (in SQL Server) mit einem Windows- / Active Directory-Konto verknüpft ist. SQL Server-Logins können keinen Identitätswechsel verwenden.
Basierend auf welchem Konto werden auf die externe Ressource zugegriffen, welche Berechtigungen haben sie für diese Ressource? Wenn es das Dateisystem ist, hat dieses Konto Schreibzugriff auf den angegebenen Pfad?
In Bezug auf das angegebene R-Beispiel (dh create C:\test1.jpg ) und unter der Annahme, dass kein Identitätswechsel verwendet wird: Ist das Konto MSSQLSERVER (oder MSSQL $ {InstanceName} ) Dienst ausgeführt als Schreibberechtigung für C: \ ? Beachten Sie, dass das Laufwerk C: des Servers ist, auf dem SQL Server ausgeführt wird, nicht Ihr lokaler Computer, es sei denn, diese Instanz von SQL Server wird auf Ihrem Computer ausgeführt.
Tags und Links sql-server r user-defined-functions clr sqlclr