SSIS über Stored Procedure aufrufen

[Eisbergle]

Ich habe folgende Aufgabe (welche "eigentlich" auch gelöst ist .. bis auf ...):

Es sollen diverse Excel-Dateien von einem Daten-Server in eine SQL-Datenbank auf einem separaten SQL-Server eingelesen werden, z.B. Kundendaten, Artikeldaten und so weiter. Das ganze läuft zum Test in einer Windows Domäne mit DC, Daten-Server, SQL-Server und Client-PC. Getestet wird hier auf den Servern und dem Client immer mit dem gleichen User, einem Domänen-Admin mit vollen Rechten auf alle Daten.

Schritt 1: Import-Prozedur (SSIS-Package) mit SQL Server Data Tools für Visual Studio. Entwickelt und getestet auf Client-PC - funktioniert. (Die Excel-Datei wird über UNC-Pfad aufgerufen)

Schritt 2: Veröffentlichen in SQL-Server. Dort SSIS-Paket getestet - funktioniert. (Problem: Der Dienst SQL Server Integration Service, muss mit Domänenrechten auf dem Daten-Server ausgeführt werden. Geändert über SQL Configuration Manager)

Schritt 3: Start über eine Stored Procedure im SQL-Management Studio auf dem SQL-Server - funktioniert.

Schritt 4: Aufruf dieser Stored Procedure über eine ACCESS-VBA-Anwendung auf dem SQL-Server - funktioniert!

So, nun zum Problem:
das ganze soll natürlich ein Anwender über die ACCESS-Anwendung auf dem Client starten. (Bitte keine Diskussionen darüber, warum das ACCESS sein muss, das Problem ist vom Frontend unabhängig. Auch Diskussionen, darüber das man das doch zeitgesteuert auf dem SQL-Server ablaufen lassen kann usw. usw. sind eigentlich nicht hilfreich, da ich nicht das ganze komplexe Anwendungsszenario darlegen möchte, das dauert zu lange und führt zu nichts.)

also wieder zu Schritt 4, jedoch auf dem Client PC:

Schritt 4: Aufruf dieser Stored Procedure über eine ACCESS-VBA-Anwendung auf dem CLIENT - FEHLER!

im SQL-Management Studio nach dem Fehler geschaut: Die Excel-Datei auf dem Daten-Server wird nicht gefunden, bzw. fehlen die Rechte.

zum Test zurück zu Schritt 3, jedoch auf dem Client PC

Schritt 3: Start über eine Stored Procedure im SQL-Management Studio auf dem CLIENT- FEHLER.
Es tritt der gleiche Fehler auf, daher kann ab diesem Moment der Test über ACCESS vernachlässigt werden.

Kopiere ich die Daten vom Server (\\server\pfad\name.xlsx) auf den SQL-Server (x:\Import\name.xlsx), so funktionieren sowohl Stored Procedure, wie auch ACCESS auch auf dem Client-PC.

So nun die eigentliche Frage zum Problem:
Ich gehe von einem Rechte-Problem aus.
Welcher Dienst oder User auf dem SQL-Server muss die Rechte auf die Daten-Datei haben.?

(Workaround könnte sein: Die Daten in der Anwendung vor dem Import auf den SQL-Server zu kopieren. Davor schrecke ich jedoch zurück, da es sehr viele und sehr umfangreiche Daten sind. Eine "saubere" Lösung ist das aus meiner Sicht zudem auch nicht)

 

[ukulele]

Also ich kenne den SSIS nicht sehr gut da ich das meiste nur an SQL Express Servern schraube und da gibt es den nicht. Daher arbeite ich viel mit OPENROWSET etc. wenn es um Zugriff auf Dateien und Importe geht. Ich lade die dann auch erst lokal auf den Server, sind i.d.R. sehr kleine Sachen.

Der Zugriff auf UNC Pfade ist wohl grundsätzlich möglich wenn der SQL Server unter einem Domänenaccount mit passenden Rechten läuft. Aber auch hier gibt es häufig Probleme, vielleicht bringt dir das hier Erleuchtung:
OpenRowSet works locally but not over networked drives

 

[Eisbergle]

Danke Ukelele,

Habe nun in den SQL-Server-Properties den Proxy mit Domänen-Admin gesetzt. aber auch das führte nicht zum Erfolg.
Es geht übrigens nicht um den UNC-Pfad auch Laufwerksmapping führt nicht zum Erfolg.

Da auf dem Server alles funktioniert nur vom Client aus nicht, denke ich, dass es tatsächlich ein lokaler Dienst auf dem Client ist der die rechte braucht. Den einzige Dienst der offensichtlich was mit SQL zu tun hat ist der SQL-VSS-Writer. Selbst wenn ich diesen mit Domänenrechten starte ändert sich nichts. Gibt es noch einen anderen Dienst?

 

[ukulele]

Nein ich glaube nicht das auf dem Client irgendein Dienst läuft. Hat der User der am Client angemeldet ist Zugriff auf den Pfad und darf dort schreiben etc.?

 

[Eisbergle]

Hallo Ukelele,
wie beschrieben wird immer mit dem gleichen User Dom-Admin getestet. D.h. er hat Rechte und kann auch darauf zugreifen.
Ich kann das SISS-Paket im Management-Studio auch direkt aufrufen ...
ich kann dieses SSISS-Pakte jedoch weder über Access noch über eine andere SP (erfolgreich) aufrufen

so sieht dann z.B. der Code aus:

DECLARE @ExcelFilePath AS sql_variant
DECLARE @Status as nchar(1)
SET @ExcelFilePath=N'\\SERVER\FREIGABE\datei.xls'
Declare @execution_id bigint
Declare @excelpath nvarchar(4000)
set @excelpath = cast(@excelfilepath as nvarchar(4000))

EXEC [SSISDB].[catalog].[create_execution] @package_name=N'Import_datei.dtsx'
, @execution_id=@execution_id OUTPUT
, @folder_name=N'ProjektFolder'
, @project_name=N'ProjektName'
, @use32bitruntime=True
, @reference_id=Null
EXEC [SSISDB].[catalog].[set_execution_parameter_value] @execution_id
, @object_type=30
, @parameter_name=N'CM.SourceConnectionExcel.ServerName'
, @parameter_value=@excelpath
DECLARE @var1 smallint = 1
EXEC [SSISDB].[catalog].[set_execution_parameter_value] @execution_id
, @object_type=50
, @parameter_name=N'LOGGING_LEVEL'
, @parameter_value=@var1
EXEC [SSISDB].[catalog].[start_execution] @execution_id​

 

[ukulele]

Hm da bin ich ratlos. Wenn du nochmal zurück gehst zu dem Schritt

Schritt 4: Aufruf dieser Stored Procedure über eine ACCESS-VBA-Anwendung auf dem CLIENT - FEHLER!

...dürfte dieser Client über ACCESS VBA und eine TestSP auch alles in der DB machen, also z.B. mal eine TestDB löschen?

 

[Eisbergle]

ja, darf er ... kein Problem, nur beim Zugriff auf Ressourcen außerhalb des SQL-Servers mag er nicht ... (der blöde Hund der blöde )