3
In T-SQL die Existenz einer Datei auf anderen Server abfragen
Hallo @all,
ich kenne zwar die Möglichkeit:
um in T-SQL die Existenz einer Datei abzufragen, ABER meines Wissens nach kann man damit nicht das Existieren einer Datei auf einem UNC-Pfad, bzw. auf einem anderen Server testen. Wie z.Bsp.
Kennt jemand eine andere Möglichkeit eine Datei auf einem anderen Server mit T-SQL zu finden.
Umgebung: MSSQL Express mit einer Standardinstallation für Express
Vielen Dank
ich kenne zwar die Möglichkeit:
DECLARE @datei_vorhanden int
EXEC master..xp_fileexist 'c:\TEMP\TEST1.txt', @datei_vorhanden OUTPUT
IF @datei_vorhanden = 1
PRINT 'Datei existiert'
ELSE
PRINT 'Datei existiert nicht.' DECLARE @datei_vorhanden int
EXEC master..xp_fileexist '\\xxx.xxx.xxx.xxx\Allgemein\TEST1.txt', @datei_vorhanden OUTPUT
IF @datei_vorhanden = 1
PRINT 'Datei existiert'
ELSE
PRINT 'Datei existiert nicht.' Umgebung: MSSQL Express mit einer Standardinstallation für Express
Vielen Dank
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5454996006
Url: https://administrator.de/contentid/5454996006
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
3 Kommentare
Neuester Kommentar
Das ist ziemlich mühselig, geht aber grundsätzlich schon, zumindest mit xp_cmdshell. Ob es noch einen eleganteren Weg gibt bin ich nicht sicher. Es gibt noch Möglichkeiten mit dem SQL Agent der aber in Express nicht enthalten ist.
1. Du musst mit xp_cmdshell auf die lokale Shell des Servers "wechseln". xp_cmdshell muss aber aus Sicherheitsgründen immer erst aktiviert werden:
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE
GO
Dann kannst du z.B. das hier ausführen:
EXEC master..xp_cmdshell 'ipconfig'
Aber: Der Zugriff erfolgt im Kontext des angemeldeten SQL-Benutzers, der sa hat lokal entsprechende Rechte. Wenn das jetzt z.B. aus einer SP und von einem anderen Benutzer ausgeführt wird dann muss der auch gewisse Systemrechte auf dem SQL Server haben. Ich habe letztes Jahr versucht dem Benutzer das Recht zu geben eine SP auszuführen die genau solche Rechte hat ohne das der Benutzer die hat, soll irgendwie gehen...
2. Mit der Shell kannst du dann auch auf remote Systeme connecten (oder Software ausführen):
EXEC master..xp_cmdshell 'winrs /r:<entfernter computer> ipconfig'
Allerdings ebenfalls im Kontext des angemeldeten Benutzers bzw. des SQL Benutzers. Daher zur Not erstmal mit:
EXEC master..xp_cmdshell 'winrs /r:<entfernter computer> /u:I<benutzer> /p:<password> ipconfig'
3. Musst du dann ein Feedback bzw. OUTPUT bekommen. Das könnte in diesem Fall gehen, in meinem Fall habe ich damit Dateien auf dem Dateisystem geschrieben und die dann verschoben und importiert.
1. Du musst mit xp_cmdshell auf die lokale Shell des Servers "wechseln". xp_cmdshell muss aber aus Sicherheitsgründen immer erst aktiviert werden:
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE
GO
Dann kannst du z.B. das hier ausführen:
EXEC master..xp_cmdshell 'ipconfig'
Aber: Der Zugriff erfolgt im Kontext des angemeldeten SQL-Benutzers, der sa hat lokal entsprechende Rechte. Wenn das jetzt z.B. aus einer SP und von einem anderen Benutzer ausgeführt wird dann muss der auch gewisse Systemrechte auf dem SQL Server haben. Ich habe letztes Jahr versucht dem Benutzer das Recht zu geben eine SP auszuführen die genau solche Rechte hat ohne das der Benutzer die hat, soll irgendwie gehen...
2. Mit der Shell kannst du dann auch auf remote Systeme connecten (oder Software ausführen):
EXEC master..xp_cmdshell 'winrs /r:<entfernter computer> ipconfig'
Allerdings ebenfalls im Kontext des angemeldeten Benutzers bzw. des SQL Benutzers. Daher zur Not erstmal mit:
EXEC master..xp_cmdshell 'winrs /r:<entfernter computer> /u:I<benutzer> /p:<password> ipconfig'
3. Musst du dann ein Feedback bzw. OUTPUT bekommen. Das könnte in diesem Fall gehen, in meinem Fall habe ich damit Dateien auf dem Dateisystem geschrieben und die dann verschoben und importiert.
Hallo SachsenHessi,
außer der Möglichkeit von ukulele gibt es auch noch die OLE-Automatisierungsprozeduren. Da sieht das dann so aus:
Aber wenn xp_fileexist bei Dir nicht funktioniert mit einem UNC-Pfad, dann wird der Weg auch nicht gehen, dann dürftest Du das von ukulele angesprochene Rechteproblem haben. Bei mir funktioniert xp_fileexist jedenfalls problemlos mit einem UNC-Pfad.
Dann bleibt Dir womöglich nur der von ukulele beschriebene Weg, Dich erstmal an dem Server anzumelden. Vielleicht eine Batchdatei, die Dich erst an dem anderen Rechner anmeldet und dann die Datei prüft.
Gruß, Mad Max
außer der Möglichkeit von ukulele gibt es auch noch die OLE-Automatisierungsprozeduren. Da sieht das dann so aus:
declare @object_id int, @FileExists bit
exec sp_OACreate 'Scripting.FileSystemObject', @object_id out
exec sp_OAMethod @object_id, 'FileExists', @FileExists out, '\\Server\Pfad\Datei.txt'
exec sp_OADestroy @object_id
select @FileExistsAber wenn xp_fileexist bei Dir nicht funktioniert mit einem UNC-Pfad, dann wird der Weg auch nicht gehen, dann dürftest Du das von ukulele angesprochene Rechteproblem haben. Bei mir funktioniert xp_fileexist jedenfalls problemlos mit einem UNC-Pfad.
Dann bleibt Dir womöglich nur der von ukulele beschriebene Weg, Dich erstmal an dem Server anzumelden. Vielleicht eine Batchdatei, die Dich erst an dem anderen Rechner anmeldet und dann die Datei prüft.
Gruß, Mad Max
Ja das kann sehr gut sein das hier einfach das Rechteproblem zu schlägt. Man ist ja häufig im SSMS als sa unterwegs und gut ist. Aber das ist natürlich ein rein lokales Konto. Gib einfach mal dem Domain Admin Rechte sich an der DB anzumelden (wenn er sie nicht schon hat) und melde damit das SSMS an. Dann müsste xp_fileexist ja auch auf dem Remote Server Rechte haben.
