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.
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
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 –