2016-11-03 50 views
14

Mam pakiet SSIS, który uruchamia zadanie skryptu (głównie i kilka innych rzeczy). Zadanie skryptowe łączy się z bazą danych Access za pomocą połączenia OleDB. To jest połączenie Microsoft Jet 4.0. Mam zainstalowane sterowniki. Ale nie będzie działać w agencie SQL za pośrednictwem konta proxy. Będzie działał dobrze bezpośrednio z Visual Studio i ze sklepu z pakietami. Tak naprawdę działa dobrze w obu tych miejscach, kiedy loguję się jako konto specjalne, z którym związany jest serwer proxy. Ale kiedy uruchamiam agenta SQL Server, pojawia się przerażający "Unspecifed Error" OleDbException.Błąd zadania agenta SQL z pakietem SSIS do dostępu DB

odpowiedni kod z zadania skryptu:

// class field 
private string accessConnectionStringTemplate = "Data Source=\"{0}\";Provider=Microsoft.Jet.OLEDB.4.0;"; 

// in method that connects to database 
Print(file, "Connection string: " + string.Format(accessConnectionStringTemplate, file.FileName)); 
// outputs: Data Source = "\Path\To\File";Provider=Microsoft.Jet.OLEDB.4.0" 
using(access = new OleDbConnection(string.Format(accessConnectionStringTemplate, file.FileName))) { 
    access.Open(); 
    // other code 
} 

Komunikaty o błędach poprzez historię pracy SQL agent:

Started: 12:35:10 PM 
Error: 2016-11-03 12:35:33.51 
    Code: 0x00000000 
    Source: Import Files Main 
    Description: Exception: Unspecified error 
End Error 
Error: 2016-11-03 12:35:33.51 
    Code: 0x00000000 
    Source: Import Files Main 
    Description: at System.Data.OleDb.OleDbConnectionInternal..ctor(OleDbConnectionString constr, OleDbConnection connection) 
    at System.Data.OleDb.OleDbConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject) 
    at System.Data.ProviderBase.DbConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions) 
    at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup, DbConnectionOptions userOptions) 
    at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) 
    at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions) 
    at System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions) 
    at System.Data.ProviderBase.DbConnectionInternal.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory) 
    at System.Data.OleDb.OleDbConnection.Open() 
    at ST_cc0028a4b56242909c2eae546a807995.csproj.ScriptMain.ImportFile(AccessFile file, DateTime startRecordDate, DateTime endRecordDate, List`1 accessTables, Boolean includeTransactionTables, List`1 specifiedTableList) 
    at ST_cc0028a4b56242909c2eae546a807995.csproj.ScriptMain.Main() 
End Error 
Error: 2016-11-03 12:35:33.51 
    Code: 0x00000006 
    Source: Import Files 
    Description: The script returned a failure result. 
End Error 

Niektóre rzeczy zrobiłem pewien:

  • dostępie sterowniki są zainstalowane i działają na serwerze, na którym działa agent SQL. Zweryfikowałem to, uruchamiając pakiet w VS jako moje konto i konto proxy, bez żadnych problemów.
  • Konto proxy ma dostęp do danego pliku. Ponownie zweryfikowano, logując się do serwera jako konto proxy. Plik znajduje się w udziale sieciowym, ale ścieżka jest określona jako ścieżka UNC.
  • Konto proxy ma dostęp do innych baz danych, które są częścią tej operacji, w celu wykluczenia wszelkich innych potencjalnych źródeł błędu.
  • Uruchamianie pakietu z magazynu pakietu (przez SSMS), ponieważ działa zarówno moje konto, jak i konto proxy. Zrobiłem to na serwerze bazy danych, aby się upewnić.

W innych pytaniach, które widziałem w Internecie na ten temat, zwykle jest to problem ze sterownikami. W tym przypadku nie jestem pewien, jak to możliwe.

Chętnie udzielę dodatkowych informacji, aby pomóc w innych diagnozach. Sam jestem całkowicie niepewny, dlaczego to nie działa.

+0

Nieparzysty, czy plik jest otwarty lub zablokowany w jakikolwiek sposób? – Siyual

+1

@Siyual: nie jest. A ponieważ jestem w stanie uruchomić go poza Agentem SQL, nie wydaje się, żeby to był problem. Przypuszczam, że możliwe jest, że ktoś otwiera to dobrze, kiedy pracuję na stanowisku agenta iw żadnym innym momencie, ale wydaje mi się to mało prawdopodobne. – siride

+0

Cóż - tutaj jest łup: nominalnie, argumenty ciągu połączenia są rozdzielane średnikami i nie lubią cytatów wokół argumentów - nawet argumentów z osadzonymi spacji. Po prostu wypróbuj cytaty. Czy to nie byłby kopacz? – Clay

Odpowiedz

6

Okazuje się, że problemem było to, że dostawca Jet próbuje pisać do katalogu temp użytkownika SQL agenta, mimo że zadanie zostało prowadzony z podszywania się jako inny użytkownik. Wydaje się, że jest to funkcja systemu podszywania się pod Windows, która nie zmienia profilu użytkownika, a jedynie token użytkownika. Skończyło się na tym kodzie:

var tempPath = Path.GetTempPath().Replace("\\SQLSERVERAGENT\\", "\\" + Environment.UserName + "\\"); 
Environment.SetEnvironmentVariable("TEMP", tempPath); 
Environment.SetEnvironmentVariable("TMP", tempPath); 

To nie jest idealne, ale działa. Oznacza to, że nie muszę udzielać uprawnień do katalogu tymczasowego agenta SQL. Tylko ten kod musi się zmienić.

Niestety, wydaje się, że nie ma możliwości zmiany w miejscu, w którym sterownik ODBC umieszcza swoje pliki tymczasowe.

EDYCJA: Też miałem ten problem z regularnym pakietem opartym na przepływie danych ze źródłem programu Excel. W tym przypadku nie miałem innego wyjścia, jak zezwolić na dostęp do katalogu tymczasowego agenta SQL dla konta mojego proxy. Jeśli uda mi się wymyślić obejście, opublikuję to.

1

Proponuję spróbować kilku rzeczy:

  1. próbuję wykonać swój pakiet w trybie cmd czyli używając składni dtexce.exe z SQL Agent (przy użyciu zarówno 32 bit i bit opcja 64).

  2. Dodaj konto usługi (agent konta SQL działa) do DCOM component for Integration Service. Jeśli możesz, zmień konto usługi agenta SQL na konto Proxy (do testowania).

  3. Zrób wszystko przy użyciu konta Proxy, tj. Wdrożyć pakiet za pomocą konta Proxy i przypisać właściciela zadania do konta Proxy (w SQL Agent). Utwórz zadanie za pomocą konta proxy.

  4. Sprawdź okno event viewer, jeśli masz błąd związany z kontem proxy lub kontem usługi agenta SQL.

  5. Jeśli korzystasz z programu SQL Server 2012 lub nowszego, zainstaluj pakiet, wypróbuj go z Integration Services Catalog.

+0

Pakiet działa i robi inne rzeczy, po prostu nie może otworzyć połączenia z tą bazą danych programu Access jako jednym z pośrednich kroków. Mogę spróbować zrobić niektóre z tych rzeczy, ale wydają się one w większości nie mieć związku z moim problemem. – siride

+0

Twój pakiet nie działa tylko z SQL Agent Job. Być może koncentrując się na ustawieniach konta usługi SQL Agent, takich jak uprawnienia/dostęp, może pomóc. To nie wygląda na problem z kontem proxy (zgodnie z twoim opisem). – p2k

+0

Działa (podobno) jako moje konto proxy, a nie jako konto usługi SQL Agent, którego nigdy nie używam. – siride