ADODB Definiowanie połączenia

Do połączenia się z bazą danych użyjemy obiektu typu ADODB.Connection. W zależności od typu bazy danych, sam łańcuch połączenia będzie przyjmował trochę inny kształt. My, w tym miejscu omówimy jedynie połączenie do bazy programu MS Access oraz MS SQL Server, co nie oznacza, że w podobny sposób nie można połączyć się z innymi typami baz przy wykorzystaniu zainstalowanego odpowiedniego sterownika.

Zacznijmy więc od definicji połączenia do bazy danych programu MS Access. Jeśli nasz plik bazy danych będzie umieszczony np. na dysku "C:" komputera i będzie miał nazwę "Northwind.mdb" (czyli będzie to baza testowa załączana z programem MS Access), to definicja będzie wyglądać następująco:


Sub access_link()

Dim cn As ADODB.Connection

Set cn = New ADODB.Connection

cn.Provider = "Microsoft.Jet.OLEDB.4.0"
cn.Open "C:\Northwind.mdb"

'-----

'polecenia wykorzystujące bazę danych

'-----

cn.Close

End Sub

Utożsamiamy zmienną "cn" z obiektem typu ADODB.Connection używając polecenia Set" = New . Następnie wystarczy podać tylko właściwość tego obiektu o nazwie Provider, gdzie po znaku równości podajemy nazwę sterownika, z którego zamierzamy korzystać. W naszym przypadku, kiedy chcemy połączyć się z bazą danych programu MS Access jest to "Microsoft.Jet.OLEDB.4.0", który na marginesie mówiąc, świetnie też sprawdza się przy podłączaniu pliku Excel jako źródło bazy danych ADODB.
Potem wystarczy już tylko wykorzystać metodę .Open podając po niej ścieżkę do pliku bazy danych. Opcjonalnie, w przypadku kiedy musielibyśmy użyć nazwy użytkownika bazy danych oraz hasła, należałoby polecenie to rozszerzyć odpowiednio o UserID i Password, oddzielone przecinkiem jako kolejne argumenty metody Open. Jeśli więc byłby to użytkownik o loginie "admin" bez hasła, to polecenie wyglądałoby następująco:


Sub access_link()

Dim cn As ADODB.Connection

Set cn = New ADODB.Connection

cn.Provider = "Microsoft.Jet.OLEDB.4.0"
cn.Open "C:\Northwind.mdb", "admin", ""

'-----

'polecenia wykorzystujące bazę danych

'-----

cn.Close

End Sub

Zauważmy, że po użyciu metody .Open i wykonaniu niezbędnych operacji na bazie danych, zawsze powinniśmy użyć metody .Close, aby zamknąć połączenie z bazą. Unikniemy dzięki temu konfliktów w dostępie do bazy, ponadto zwolnimy niepotrzebne zasoby.

Drugi przypadek, jaki chciałbym zaprezentować czytelnikom, to połączenie z bazą MS SQL Server. Całość wygląda bardzo podobnie, poza podaniem innego sterownika we właściwości .Provider oraz trochę innego łańcucha do metody .Open. Załóżmy, że SQL Server działa na komputerze o IP równym 10.10.10.1, korzystając z bazy nazwanej "moja_baza", użytkownik będzie miał login "admin" i hasło "haslo". Całość będzie wyglądać następująco:


Sub access_link()

Dim cn As ADODB.Connection

Set cn = New ADODB.Connection

cn.Open "Provider=SQLOLEDB;Data Source='10.10.10.1';Initial Catalog='moja_baza';User ID='admin';Password='haslo'"

'-----

'polecenia wykorzystujące bazę danych

'-----

cn.Close

End Sub

Zauważmy, że tym razem wszystkie właściwości/parametry (także Provider) umieściliśmy w łańcuchu polecenia, dzięki czemu kod jest jeszcze prostszy. Jako sterownik podajemy "SQLOLEDB", Data Source jest tym razem odniesieniem do IP serwera/komputera, na którym działa SQL Server (możemy ten argument podać także jako odwołanie do aliasu serwera w sieci, gdyby np. SQL Server działał na komputerze o nazwie sieciowej "sqlserver" to taką właśnie moglibyśmy tu podać, zamiast IP). "Initial Catalog" - oznacza nazwę bazy danych, którą zamierzamy wykorzystywać podczas połączenia. W kolejnych argumentach podajemy "User ID" oraz "Password" (czyli login i hasło użytkownika SQL Servera). Jest to wymagane przy ustawieniach autentykacji typu "SQL Server Authentication".
Nie będziemy się specjalnie rozwodzić nad tematem autentykacji użytkowników na serwerze SQL, ale co do zasady mamy dwie możliwości: albo działamy przy użyciu loginu i hasła (i łączymy się z poziomu języka VBA jak powyżej), albo mamy zastosowaną tzw. "Autentykację Windows" - wówczas serwer poznaje użytkownika zalogowanego na komputerze i o ile administrator nadał temu użytkownikowi określone uprawnienia, to może on korzystać z jego zasobów, bez podawania dodatkowego loginu i hasła. W takiej sytuacji zamiast "User ID" oraz "Password" użyć należałoby właściwości "Integrated Security=SSPI".

Na koniec wspomnę tylko o jednym istotnym elemencie praktycznym: o ile nie używamy autentykacji systemu Windows, warto przechowywać łańcuch polecenia np. w ukrytym i zabezpieczonym hasłem arkuszu, lub jakimkolwiek innym, dowolnie zabezpieczonym pojedynczym miejscu aplikacji, lub dysku komputera. Ewentualnie można wczytywać go raz i przechowywać np. w zmiennej globalnej, ale ta metoda bywa zawodna (różnego rodzaju interakcje aplikacji z plikami zewnętrznymi, potrafią skutecznie oczyścić zawartość tych zmiennych, mimo że teoretycznie nie powinny - ponadto jest to rezerwowanie pamięci komputera, niewielkie ale zawsze).
Przechowywanie łańcucha połączenia w pojedynczym, dowolnie zabezpieczonym miejscu zapewni nam łatwą migrację aplikacji w sytuacji, kiedy serwer SQL zostałby przeniesiony przez administratora sieci do innej lokalizacji. Unikniemy wówczas zmieniania tych danych w całym projekcie - oczywiście można użyć w oknie edycji polecenia Ctrl+H i zmienić teksty wszędzie w całym projekcie, jednak ja osobiście odradzam takie podejście. W każdej aplikacji, którą użytkownicy będą tworzyć (i nie tylko w VBA pod Excel) dobrą praktyką jest przechowywanie takich informacji na poziomie globalnym (niejako obok kodu) w nim samym jedynie odwołując się do obiektów, w których te informacje są zawarte.

Excel - makra i VBA