Aus stored procedure in Datei auf dem Dateisystem schreiben

ukulele

ukulele

Datenbank-Guru
Beiträge
5.168
Ich versuche eine Batch-Datei aus einer stored procedure zu erzeugen, auf dem Dateisystem abzulegen und dann auszuführen. Habe hier auch einen Beitrag gefunden:
blog.sqlauthority.com

How to Write in Text File from T-SQL in SQL Server? - Interview Question of the Week #236 - SQL Authority with Pinal Dave

Question: How to Write in Text File from T-SQL in SQL Server? The question above was actually asked in an interview and also was not asked in the same word.
blog.sqlauthority.com blog.sqlauthority.com

Damit versuche ich eine Textdatei auf dem Dateisystem abzulegen. Der Demo-Code (unverändert) läuft ohne Fehler durch aber sp_OAMethod tut einfach gar nichts auf dem Dateisystem.

Server ist SQL Express 2014, ausführen tue ich das auch dem SSMS als sa. Ist das ein Rechteproblem?
 
Werbung:
checking return value and close file
Vielleicht sowas.
Ansonsten kann ich mir vorstellen, dass da mittlerweile auch zusätzliche Sicherheitsmechnismen hinter stecken, vor allem, wenn am Ende CMD Files geschrieben werden (executables), so ähnlich wie bestimmte Attachments in Outlook. (Ich hab keine Ahnung von aktuellen MS SQL Servern.)
 
ukulele schrieb:
Ich versuche eine Batch-Datei aus einer stored procedure zu erzeugen, auf dem Dateisystem abzulegen und dann auszuführen. Habe hier auch einen Beitrag gefunden:
blog.sqlauthority.com

How to Write in Text File from T-SQL in SQL Server? - Interview Question of the Week #236 - SQL Authority with Pinal Dave

Question: How to Write in Text File from T-SQL in SQL Server? The question above was actually asked in an interview and also was not asked in the same word.
blog.sqlauthority.com blog.sqlauthority.com

Damit versuche ich eine Textdatei auf dem Dateisystem abzulegen. Der Demo-Code (unverändert) läuft ohne Fehler durch aber sp_OAMethod tut einfach gar nichts auf dem Dateisystem.

Server ist SQL Express 2014, ausführen tue ich das auch dem SSMS als sa. Ist das ein Rechteproblem?
Zum Vergrößern anklicken....
Vielleicht hilft Dir das hier weiter The TSQL of Text Files - Simple Talk
 
dabadepdu schrieb:
checking return value and close file
Vielleicht sowas.
Ansonsten kann ich mir vorstellen, dass da mittlerweile auch zusätzliche Sicherheitsmechnismen hinter stecken, vor allem, wenn am Ende CMD Files geschrieben werden (executables), so ähnlich wie bestimmte Attachments in Outlook. (Ich hab keine Ahnung von aktuellen MS SQL Servern.)
Zum Vergrößern anklicken....
Also den Debugging-Code habe ich mal getestet und bekomme die Meldung:
Error -2146828212 opening file.
Zum Vergrößern anklicken....
Ich weiß also an welcher Stelle es hakt aber die Erkenntnis hält sich in Grenzen. Ich vermute stark ein Rechteproblem. Wenn ich es in eine SP packe und die gezielt mit EXECUTE AS aufrufe bekam ich gestern noch einen anderen Fehler weil auf irgendeine System-DB (die ich nicht kenne und auch nicht finde) nicht zugegriffen werden konnte. Das kriege ich leider nicht mal reproduziert...

Irgendwie ist mir die ganze Lösung suspekt, auch weil ich sie nicht richtig durchschaue. Scheint mir der "modernere Weg" zu sein aber laufen muss es natürlich zuverlässig.

t-sql schrieb:
Vielleicht hilft Dir das hier weiter The TSQL of Text Files - Simple Talk
Zum Vergrößern anklicken....
Das sieht interessant aus. Ich wollt es erst mit xp_cmdshell frickeln aber das kann nur bis 255 Zeichen gleichzeitig an die Shell durchreichen, da sieht das mit bcp besser aus. Das werde ich heute noch testen.
 
ukulele schrieb:
Also den Debugging-Code habe ich mal getestet und bekomme die Meldung:
[QOUTE]Error -2146828212 opening file.Ich weiß also an welcher Stelle es hakt aber die Erkenntnis hält sich in Grenzen. Ich vermute stark ein Rechteproblem. Wenn ich es in eine SP packe und die gezielt mit EXECUTE AS aufrufe bekam ich gestern noch einen anderen Fehler weil auf irgendeine System-DB (die ich nicht kenne und auch nicht finde) nicht zugegriffen werden konnte. Das kriege ich leider nicht mal reproduziert...
Zum Vergrößern anklicken....
Das ist sogar ziemlich sicher ein Rechteproblem. Der User mit dem SQL Server läuft braucht die Berechtigungen dazu. Das hat mit internen SQL Server Berechtigungen nix zu tun
 
ukulele schrieb:
Also den Debugging-Code habe ich mal getestet und bekomme die Meldung:

Ich weiß also an welcher Stelle es hakt aber die Erkenntnis hält sich in Grenzen. Ich vermute stark ein Rechteproblem. Wenn ich es in eine SP packe und die gezielt mit EXECUTE AS aufrufe bekam ich gestern noch einen anderen Fehler weil auf irgendeine System-DB (die ich nicht kenne und auch nicht finde) nicht zugegriffen werden konnte. Das kriege ich leider nicht mal reproduziert...
Zum Vergrößern anklicken....
Bei execute as dürfte aber kein Fehler auftreten. Weißt du vielleicht noch welche Fehlermeldung Du bekommen hast?
 
Der SQL Express Service muss ja sicher explizite Dateizugriffsrechte bekommen. Zumindest ist das bei anderen DB so. In Oracle gibt es dazu sogar explizite Objekte. Directory Objekte, die muss man anlegen und granten. Aber das ist innerhalb der DB. Ändert nichts daran, dass der Dienst selbst dann Dateizugriff haben muss (an der Stelle, wo die Datei erzeugt werden soll).
Notfalls mal an einer "unverfänglichen" Stelle testen, wo bspw. eh logs geschrieben werden oder app roaming.
Apropos logs, gibt es keine Hinweise in den Ereignissen / Server Logs?

Außerdem gibt es in den Dienstaufrufen / Konfiguration einen Schalter "Datenaustausch zwischen Dienst und Desktop erlauben", hilft manchmal, nur eine Idee.
 
Ich glaube es war
Die EXECUTE-Berechtigung wurde für das xp_cmdshell-Objekt, mssqlsystemresource-Datenbank, sys-Schema, verweigert.
Zum Vergrößern anklicken....
Kommt jetzt auch wenn ich
Code: 
    EXECUTE AS USER = 'DOMAIN\Administrator';
    EXEC master..xp_cmdshell 'bcp "SELECT ''abc''" queryout "D:\test\asdf.txt" -c -T'
    REVERT
mache, ich scheitere irgendwie immer am Zugriff.
 
ukulele schrieb:
EXECUTE AS USER = 'DOMAIN\Administrator'
Zum Vergrößern anklicken....
Entspricht das denn einem realen Account auf Deinem Rechner bzw. in der Domaine "DOMAIN"?
Du hast doch hier 2 Contexte: Einen OS Context, in dem Dateizugriffsrechte vorliegen müssen und den DB Context, der Grants für das Ausführen der SP benötigt.
'DOMAIN\Administrator' klingt nach einem Beispielaccount. Oder arbeitest Du dort als Administrator der Domaine auf dem System?
So oder so, die Anweisung "Execute as.." kann ja auch bereits scheitern. Wenn das jeder einfach aufrufen könnte, wäre es sinnlos oder? Es gibt ja UAC nicht zufällig.
Angenommen es ist erfolgreich (welcher User auch immer), mit welchem OS Konto letztlich der Dateizugriff erfolgt.

Schau mal hier:
stackoverflow.com

Execute xp_cmdshell command as specific user

I would like to run xp_cmdshell (TSQL procedure) in order to mount a network drive and then access remotes mdb files. I am administrator on the MS SQL server and I have allowed xp_cmdshell execution
stackoverflow.com stackoverflow.com
 
Also ein bisschen weiter bin ich.

DOMAIN habe ich nur fürs Forum eingetragen, ich nehme natürlich meine Domain. Ich habe außerdem jetzt einen eigenen Domänen-Benutzer angelegt, also DOMAIN\sqltofile. Der hat jetzt Zugriff auf NTFS-Ebene, hat public auf die master DB und auf die im SSMS grade ausgewählte DB (da hat er sonst gemeckert). Außerdem hat er
SQL: 
GRANT EXECUTE ON master..xp_cmdshell TO [DOMAIN\sqltofile];

Jetzt müsste ich lt. Getting execute permission to xp_cmdshell noch einen Proxy Account für xp_cmdshell anlegen, habe ich auch versucht mit
SQL: 
EXEC sp_xp_cmdshell_proxy_account 'DOMAIN\sqltofile','pw'
aber
Fehler beim Ausführen von sp_xp_cmdshell_proxy_account. Mögliche Ursachen: Das bereitgestellte Konto war ungültig, oder die ##xp_cmdshell_proxy_account##-Anmeldeinformationen konnten nicht erstellt werden. Fehlercode: '1326(Der Benutzername oder das Kennwort ist falsch.)', Fehlerstatus: 0.
Zum Vergrößern anklicken....
Das ist mir grade noch nicht klar.
 
Oh Gott ist das nervig. Statt
SQL: 
EXEC sp_xp_cmdshell_proxy_account 'DOMAIN\sqltofile','pw'
habe ich es über die GUI gemacht und er hat mir draus
SQL: 
CREATE CREDENTIAL [##xp_cmdshell_proxy_account##] WITH IDENTITY = N'INTERN\sqltofile', SECRET = N'a3uR2SSgVbUhjUJ7YZewcNTpIgrQB5kAFcqSA7nA'
generiert aber wie auch immer, die Credentials sind wohl da wo sie sein sollten.

Nur funktionieren tut es natürlich nicht:
SQL: 
EXECUTE AS USER = 'DOMAIN\sqltofile';
EXEC master..xp_cmdshell 'bcp "SELECT ''abc''" queryout "D:\test\asdf.txt" -c -T'
REVERT
liefert
Fehler während der Ausführung von xp_cmdshell. Fehler beim Aufrufen von 'LogonUserW' (Fehlercode: '1385').
Zum Vergrößern anklicken....
Nach allem was ich gelesen habe sind die Berechtigungen da. Das Passwort habe ich auch nochmal neu gesetzt. Ein Neustart ist meine letzte Hoffnung.
 
Den Fehler kriege ich immer wenn ich EXECUTE AS USER irgendwas machen lassen will, auch bei DOMAIN\Administrator. Also irgendwas raffe ich hier nicht und das wird echt zum Problem.
 
Werbung:
Zurück
Oben