2012-03-19 13 views
9

Witam Mam skonfigurowane ustawienia DSN dla vertica w maszynie 32-bitowej wersji systemu Ubuntu 10.10. Ustawienia są w porządku, a ja je sprawdziłem.UnixODBC podając błąd podczas działania isql [Vertica]

Oto moja ODBC.INI file:

[VerticaDSN] 
    Description = VerticaDSN ODBC driver 
    Driver = /opt/vertica/lib/libverticaodbc_unixodbc.so 
    Servername = myservername 
    Database = mydbname 
    Port = 5433 
    UserName = myuname 
    Password = ******* 
    Locale = en_US 

Podobnie mam ODBCINST.INI pliku.

kiedy uruchomić polecenie: isql -v VerticaDSN pojawia się następujący błąd:

[S1000][unixODBC][DSI] The error message NoSQLGetPrivateProfileString could not be found in the en-US locale. Check that /en-US/ODBCMessages.xml exists. 
[ISQL]ERROR: Could not SQLConnect. 

Próbowałem wszystkiego, ale nie jestem w stanie rozszyfrować ten błąd.

Każda pomoc zostanie bardzo doceniona.

+0

Jakie wersje sterownika bazy danych i Vertica pracujesz? Ponadto zwykle nie określam ustawień regionalnych w moich połączeniach ODBC. Czy na pewno go potrzebujesz? To brzmi bardziej jak błąd lokalizacji niż błąd użytkownika, ale mogę się mylić. – bpanulla

+0

Usunąłem go bez skutku. Używam teraz sterownika vertica_5.1.1_odbc_i386_linux vertica. Śledziłem instrukcję isql, ale nadal wyszukuje plik vertica.ini. Czy istnieje taki plik? Wydaje mi się, że to je wydaje –

Odpowiedz

14

Być może brakuje sekcji Konfiguracja sterownika. Edytować lub tworzyć /etc/vertica.ini plików z następującej treści:

[Driver] 
DriverManagerEncoding=UTF-16 
ODBCInstLib=/usr/lib64/libodbcinst.so 
ErrorMessagesPath=/opt/vertica/lib64 
LogLevel=4 
LogPath=/tmp 

Więcej informacji można znaleźć w podręczniku Vertica programisty w sekcji „Lokalizacja Dodatkowych ustawień sterownika”.

+0

tak, w moim przypadku to był dokładny problem. –

+0

Dziękuję! to prosto do rzeczy. – MohamedEzz

1

Z błędu widzimy, że korzystasz z unixODBC i przypuszczam, że "DSI" jest tym, co Vertica nazywa się, ponieważ tekst błędu ODBC jest sformatowany z wpisami w [] od lewej do prawej, jak ścieżka przez różne składniki (patrz Example diagnostic messages).

Zakładam, że komunikat powinien brzmieć "Nie można znaleźć SQLGetPrivateprofileString". SQLGetPrivateProfileString to interfejs API udostępniany przez menedżera sterowników ODBC do odczytu wpisów z pliku odbc.ini. Sądzę, że należy je znaleźć w libodbcinst.so wspólnym obiekcie jednak niektóre dystrybucje (np. Ubuntu/Debian) usuwają symbole z udostępnianych obiektów, więc trudno jest to zweryfikować.

W twoim DSN, sterownik jest plikiem "/opt/vertica/lib/libverticaodbc_unixodbc.so". Chociaż zwykle jest to nazwa sterownika w odbc.ini i dodanie wpisu do pliku odbcinst.ini, twoje DSN wygląda dobrze. np:

/etc/odbcinst.ini: 
[Easysoft ODBC-SQL Server SSL] 
Driver=/usr/local/easysoft/sqlserver/lib/libessqlsrv.so 
Setup=/usr/local/easysoft/sqlserver/lib/libessqlsrvS.so 
Threading=0 
FileUsage=1 
DontDLClose=1 

/etc/odbc.ini: 
[SQLSERVER_SAMPLE_SSL] 
Driver=Easysoft ODBC-SQL Server SSL 
Description=Easysoft SQL Server ODBC driver 
. 
. 

Patrz w powyższym przykładzie robi to w ten sposób pozwala określić dodatkowe opcje związane z kierowcą jak Threading (i szybkiego wyszukiwania w internecie sugeruje Vertica można wykorzystać Threading = 1, która jest mniej restrykcyjne, jeśli przy użyciu programu z gwintem) i DontDLClose. Jednak, jak już powiedziałem, rzeczy powinny działać tak jak teraz.

Teraz następny bit zależy od twojej platformy i nie zauważyłem, że ją podałeś. Musisz zbadać ten obiekt współdzielony dla sterownika ODBC i zobaczyć, od czego to zależy. W systemie Linux można zrobić coś takiego:

$ ldd /usr/local/easysoft/sqlserver/lib/libessqlsrv.so 
    linux-gate.so.1 => (0xb76ff000) 
    libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 (0xb75fe000) 
    libesextra_r.so => /usr/local/easysoft/lib/libesextra_r.so (0xb75fb000) 
    libessupp_r.so => /usr/local/easysoft/lib/libessupp_r.so (0xb75de000) 
    libeslicshr_r.so => /usr/local/easysoft/lib/libeslicshr_r.so (0xb75cd000) 
    libestdscrypt.so => /usr/local/easysoft/lib/libestdscrypt.so (0xb75c8000) 
    libm.so.6 => /lib/libm.so.6 (0xb75a2000) 
    libc.so.6 => /lib/libc.so.6 (0xb7445000) 
    libltdl.so.7 => /usr/lib/libltdl.so.7 (0xb743b000) 
    libpthread.so.0 => /lib/libpthread.so.0 (0xb7421000) 
    /lib/ld-linux.so.2 (0xb7700000) 
    libdl.so.2 => /lib/libdl.so.2 (0xb741d000) 

który pokazuje ten sterownik ODBC zależy libodbcinst.so.1 i dynamiczny linker znalazł. Wyobrażam sobie, że sterownik Vertica powinien wyglądać podobnie pod tym względem, chociaż jest możliwe, że sterownik Vertica dynamicznie ładuje ten obiekt współdzielony sam podczas pierwszego ładowania. Tak czy inaczej, wygląda na to, że sterownik Vertica nie może znaleźć symbolu SQLGetPrivateProfileString, który jest w libodbcinst.so, więc upewnij się, że a) masz libodbcinst.so b) twój dynamiczny linker wie o tym (jak to się robi zależy od twojej platformy - w systemie Linux zobacz /etc/ld.so.conf i LD_LIBRARY_PATH oraz stronę podręcznika ld.so) c) uruchom ldd (lub odpowiednik), aby nie było brakujących zależności.

Plik vertica.ini jest prawdopodobnie miejscem, gdzie sterownik przechowuje konfigurację określoną przez sterownik - niektóre sterowniki to robią. Jeśli format tego pliku jest podobny do plików odbc powyżej, może również użyć SQLGetPrivateProfileString dla tego pliku, ponieważ możesz stwierdzić, który interfejs ODBC API będzie używany.

Poza tym nie mam więcej pomysłów poza kontaktem vertica.

0

Arun - jeśli możesz dać mi znać wersję bazy danych i wersję sterownika, mogę uzyskać więcej szczegółów. Mogę też spróbować opublikować to na oficjalnym forum społeczności Vertica.

http://my.vertica.com/forums/forum/application-and-tools-area/client-drivers/

Gdybym miał zgadywać, co twój problem to myślę, że może to być związane z tym poście:

http://my.vertica.com/forums/topic/odbc-on-linux-issue/

... konkretnie komentarz na końcu o „ODBCInstLib” .

2

Wyszukiwanie w Internecie na ten temat Widziałem, że mnóstwo ludzi było w stanie połączyć się z tsql, ale nie z isql lub osql (który używa isql). Miałem ten sam problem i badałem i testowałem przez ostatni tydzień próbując dowiedzieć się, o co chodzi. Rzecz w tym, że wszyscy podeszli do niego z punktu widzenia ODBC, kiedy to, co moim zdaniem jest, ma coś wspólnego z serwerem Windows lub konfiguracją serwera sql. Sprawdziłem logi na serwerze Windows i widziałem, że komputer z uruchomionym ODBC uderzył i próbował wielokrotnie się logować, ale nie był w stanie. W przeglądarce zdarzeń znajduje się mnóstwo wpisów pokazujących to samo, co komputer klienta próbuje zalogować się do SQL Server, ale jest odrzucany przez maszynę hosta. To jest kąt, na którym się teraz skupiam i gdzie myślę, że problem leży. Jeśli otrzymam to rozwiązanie, opublikuję ponownie, informując wszystkich o tym, co dowiedziałem się o tym problemie.

Dziękujemy,

+0

Dzięki Jamatrix, jest to naprawdę doceniane –

Powiązane problemy