Artykuły

A A A
Drukuj Ekportuj do PDF
Opublikowane: 2002.06.22 15:24 | Jacek Kolonko | Aktualizacja: 2006.01.23 19:04

Osadzanie MSDE 2000 w programie instalacyjnym własnej aplikacji

Microsoft SQL Server 2000 Desktop Engine (MSDE) to darmowa wersja SQL Server 2000, funkcjonalnie odpowiadająca pełnej wersji serwera. Ma pewne ograniczenia - może obsługiwać mniejsze bazy danych, a także nie jest zoptymalizowana pod kątem pełnego wykorzystania mocy komputera - np. ograniczona jest liczba równolegle przetwarzanych operacji. Jednak wszystko to sprawia, że jest to doskonały motor bazodanowy który w wielu przypadkach może zastąpić np. motor JET (Microsoft Access).

Microsoft® SQL Server™ 2000 Desktop Engine (MSDE 2000) umożliwia dostawcom oprogramowania osadzenie baz danych w swoich własnych aplikacjach. Artykuł ten wskazuje, w jaki sposób można rozprowadzać MSDE 2000 wraz z własną aplikacją osadzając MSDE 2000 w programie instalacyjnym danej aplikacji.

MSDE 2000 to lokalna baza danych zgodna ze SQL Server. Można rozważać MSDE 2000 jako alternatywę typu klient/serwer dla motoru bazy danych Microsoft Jet. MSDE 2000 jest zaprojektowany i zoptymalizowany dla małych systemów komputerowych, takich jak pojedyncze komputery, lub małe serwery z niedużą liczbą równoczesnych połączeń.

MSDE 2000 jest rozprowadzany jako zbiór 25 modułów. Jednostanowiskową instalację MSDE 2000 można wykonać, używając pliku MSI dostarczanego ze SQL Server Setup. (w następnym podrozdziale wyjaśnione jest pojęcie MSI). Możesz również osadzić MSDE 2000 Setup w dowolnym własnym programie instalacyjnym, używając jego modułów. Osadzenie MSDE 2000 we własnym programie Setup łączy moduły merge w pakiet MSI.

Tworzenie własnej aplikacji z MSDE 2000 osadzonym w programie instalacyjnym jest procesem trójfazowym, na który składają się:

  1. Tworzenie pakietu MSI potrzebnego do instalacji własnej aplikacji.
  2. Włączenie modułów merge MSDE 2000 do aplikacji.
  3. Uruchomienie programu Setup w celu instalacji własnej aplikacji oraz MSDE 2000.

MSDE 2000 jest instalacją bazującą na instalatorze Microsoft Windows® (Windows Installer). Podrozdział Instalator Windows i Merge Moduły to pobieżny opis instalatora oraz modułów – składowych instalacji. Można także przejrzeć zasoby Instalatora Windows i Merge Modułów, aby dowiedzieć się więcej na temat cech MSDE 2000 i możliwości Instalatora Windows. Tworzenie pakietu MSI omawia kolejne kroki tworzenia pakietu MSI. Następne paragrafy opisują moduły merge oraz rzeczy istotne dotyczące procesu łączenia. Dodatek A zawiera odpowiedzi na najczęściej zadawane pytania.

Instalator Windows i Merge Moduły

Instalator Windows, który wchodzi w skład Microsoft Platform SDK, to bardzo silne narzędzie, używane do instalowania oprogramowania w środowisku Windows. Instalator zapisuje informacje w postaci zbioru tabel i tworzy pakiety, zwane pakietami MSI. Uruchomienie takiego pakietu powoduje zainstalowanie produktu w środowisku.

Moduły merge to pliki o rozszerzeniu .msm. Moduł tego typu nie może sam siebie zainstalować, ponieważ brakuje mu niektórych informacji znajdujących się w dodatkowych tabelach (określających dokładnie, jak będzie wyglądała instalacja). Znajdują się one w bazie instalacyjnej − plikach .msi. Moduły merge zawierają dodatkowe tabele, specyficzne tylko dla nich. Aby zainstalować moduły razem z aplikacją, muszą być one najpierw dołączone do pliku .msi aplikacji.

Każdy moduł posiada tabelę sygnatury, której zawartość definiuje sygnaturę, czyli podpis modułu. Gdy włączenie modułu do MSI kończy się sukcesem, jego sygnatura dodawana jest do tabeli sygnatur MSI.

Programiści, którzy chcą korzystać z merge modułów, mogą ściągnąć bezpłatny zestaw narzędzi do ich łączenia lub zakupić jedną z komercyjnych aplikacji rozprowadzanych przez niezależnych sprzedawców oprogramowania. Mergemod.dll dostarcza obiekt COM, który zawiera operacje łączenia i generowania obrazu źródłowego dla merge modułów. Orca − edytor bazy danych dostarczany wraz z Windows Installer SDK − także używa obiektu COM w swojej implementacji operacji połączenia. Jest to bardzo silne narzędzie do łączenia MSM.

Główną zaletą merge modułów jest łatwość ich używania. Można osadzić moduły MSDE 2000 we własnym MSI, sprawiając tym samym, by instalacja aplikacji oraz MSDE 2000 dokonywała się w jednym procesie.

Aby uzyskać więcej informacji na temat Instalatora Windows, zobacz Stronę startową Instalatora Windows w pakiecie Platform SDK.

Aby uzyskać więcej informacji na temat MSDE 2000, zobacz SQL Server 2000 Desktop Engine (MSDE 2000).

Tworzenie pakietu MSI

Aby utworzyć pakiet MSI, należy wykonać następujące kroki:

  1. Zaplanować instalację. Należy opracować ogólny schemat instalacji − pliki, katalog źródłowy, katalog docelowy. Następnie należy wypisać również wszystkie operacje związane z rejestrem czy ustawianiem konfiguracji, a potem umieścić instalowany plik .EXE w określonym katalogu. Pozostałe potrzebne do instalacji pliki można umieścić w tym samym katalogu lub w jego podkatalogach.
  2. Stworzyć pustą bazę danych. Aby utworzyć pakiet MSI, trzeba skopiować lub stworzyć plik bazy Instalatora Windows. Pusta baza instalacyjna Schema.msi jest dostarczana wraz z komponentami Microsoft Platform SDK dla programistów Instalatora Windows. SDK dostarcza również częściowo pustą bazę Uisample.msi, która zawiera sugerowane tabele i dane potrzebne dla prostego interfejsu użytkownika. Teraz można skopiować Uisample.msi do katalogu zawierającego instalowany plik .exe. Baza instalacyjna i pliki źródłowe muszą znajdować się w tym samym katalogu (większą liczbę plików można rozmieścić w jego podkatalogach), w przeciwnym wypadku Setup zgłosi błąd.
  3. Określić strukturę katalogów. Program instalacyjny zapisuje informację o strukturze katalogu tworzonego przez program instalacyjny w tabeli katalogu (Directory table). Przy użyciu edytora bazy Orca lub innego programu można do tej tabeli dodać odpowiednie informacje.
  4. Sporządzić listę komponentów składowych Teraz trzeba wypisać wszystkie składniki, które są częścią instalacji. Składnikiem może być lista plików lub zasobów, które są dodane do tabeli komponentów bazy danych.
  5. Określić pliki i ich atrybuty. Następnie należy dodać wszystkie związane z instalacją pliki do tabeli plików (Files table).
  6. Wprowadzić informację o nośnikach źródłowych do tabeli nośników. Tabela nośników (Media table) zawiera informacje o zbiorze dysków, które zawierają dane źródłowe potrzebne w procesie instalacji.
  7. Zdefiniować odpowiednie składniki (features) instalacji. Kolejnym krokiem jest dodanie cechy produktu do tabeli składników (Feature table). Instalator pozwala użytkownikowi na dokonywanie zmian funkcjonalności aplikacji poprzez określenie tzw. cech instalacji. Podczas łączenia MSDE 2000 z własną aplikacją można zdefiniować MSDE 2000 jako oddzielną cechę lub związać go z jedną z istniejących już cech, a następnie utworzyć wzorzec oddzielnego składnika dla MSDE 2000, jeśli chcemy zainstalować go jako oddzielną cechę.
  8. Zdefiniować relacje między komponentami a składnikami. Relacje między składnikami i komponentami można określić w tabeli komponentów składników (FeatureComponents table). Każdy Instalator Windows używa jednego lub więcej komponentów. Składniki mogą współdzielić komponenty.
  9. Dodać informację wymaganą dla rejestru oraz właściwości skrótu. Tabela rejestru (Registry table) i inne tabele związane z procesem instalacji zawierają informację, która musi zostać umieszczona w rejestrze systemu. Tabela skrótu (Shortcut table) i inne związane z instalacją tabele zawierają informację niezbędną do instalacji skrótu.
  10. Określić właściwości. Właściwości Instalatora Windows są to globalne zmienne, które program wykorzystuje podczas instalacji. Nie trzeba definiować wszystkich właściwości w każdym pakiecie − niektóre z nich są jednak potrzebne. Instalator ustala wartości poszczególnych właściwości w określonym porządku.
  11. Wypełnić tabele sekwencji. Teraz należy wypełnić następujące tabele: InstallExecuteSequence, InstallUISequence, AdminExecuteSequence, AdminUISequence oraz AdvtExecuteSequence.
  12. Dodać krótką informację o instalacji. Informacja ta nie jest niezbędna do uruchomienia programu Setup, aby jednak pakiet mógł zostać w prawidłowy sposób zatwierdzony, jest ona konieczna. Przy wprowadzaniu tej informacji można wykorzystać MsiInfo.exe, który jest dostarczany wraz z Windows Installer SDK.

Co jest potrzebne, aby operacja połączenia zakończyła się sukcesem?

Zanim rozpoczniemy łączenie modułów MSDE 2000 ze swoją aplikacją, trzeba przeprowadzić sprawdzanie poprawności, wprowadzić niezbędne modyfikacje do tabeli nośników oraz zaplanować rozwiązanie w przypadku pojawienia się konfliktu.

Sprawdzanie poprawności

Sprawdzenie poprawności polega na przeszukaniu bazy pod kątem błędów, będących przyczyną nieprawidłowego zachowania w kontekście całej bazy danych. Próba instalacji pakietu, który nie przeszedł pomyślnie sprawdzania poprawności, może doprowadzić do uszkodzenia systemu użytkownika. Zawsze należy sprawdzić poprawność pakietu przed jego instalacją oraz po wprowadzeniu do niego jakichkolwiek zmian. Można do tego użyć edytora Orca lub Msival2.exe (oba dostarczane są wraz z Windows Installer SDK). Teraz trzeba sprawdzić zarówno dołączany moduł, jak i MSI. Aby operacja połączenia zakończyła się sukcesem, tabele poprawności MSM i MSI muszą być ze sobą zgodne.

Zmiana tabeli nośników

W tabeli nośników Media table znajduje się kolumna, zwana LastSequence, która zawiera numer porządkowy ostatniego pliku na nośniku źródłowym. Numer ten musi zostać zmieniony (zwiększony) w celu włączenia plików z MSM. Tu trzeba wpisać wartość, która jest najwyższa ze wszystkich numerów porządkowych plików (zawartych w tabeli plików File table) ze wszystkich MSM, aby wskazać, że wszystkie one muszą zostać włączone.

Rozwiązywanie konfliktu połączenia

Zdarza się, że zawartość jednego z głównych pakietów MSI częściowo pokrywa się z zawartością pakietu MSM. W takich przypadkach rekordy muszą być identyczne. Jeśli nie są − pojawia się konflikt podczas połączenia. Na przykład w tabeli poprawności MSI zawartość może być zadeklarowana jako string, zaś to samo w tabeli poprawności MSM − jako formatted. W takim przypadku wystąpi konflikt i wartości te muszą zostać ujednolicone. Sprawdzanie każdego rekordu krok po kroku jest niewygodne. Dlatego najlepszą metodą jest uruchomienie połączenia i korygowanie niespójności w momencie wystąpienia błędu.

Techniki łączenia

Ta część artykułu opisuje, jak wykorzystywać edytor Orca podczas łączenia pakietów.

Łączenie przy wykorzystaniu interfejsu użytkownika

Orca 1.5 beta i wersje późniejsze pozwalają łączyć pakiet przy użyciu interfejsu użytkownika. Funkcje Mergemod.dll mogą być wywoływane z menu narzędziowego (Tools menu) tej wersji edytora Orca. Wersje wcześniejsze umożliwiają łączenie modułów w oparciu o skrypty.

Okno dialogowe połączenia jest wywoływane z menu narzędziowego Orca. Jest ono widoczne na poniższej ilustracji.

ORCA

Rysunek 1. Okno dialogowe merge edytora Orca

W celu przyłączenia danego MSM należy wykonać następujące kroki:

  1. Kliknąć przycisk Browse i wybrać moduł MSM do połączenia.
  2. Z pozycji Root Directory wybrać katalog docelowy instalacji. Domyślnie Instalator Windows używa zmiennej TARGETDIR do wskazania katalogu do instalacji. W przypadku błędnego wyboru zostanie zgłoszony błąd (przy naciśnięciu OK).
  3. Wybrać element instalacji (ang. feature), do której MSM ma zostać dołączone. Każdy MSM musi być związany z jakąś cechą MSI. Można stworzyć nowy element − cechę lub wykorzystać już istniejącą. Moduł zostanie zainstalowany tylko wtedy, gdy jest zainstalowana ta szczególna cecha. Dobrym zwyczajem jest tworzenie pojedynczej cechy właściwej dla MSDE 2000 i związanie z nią wszystkich pakietów MSDE.
  4. Wybrać opcję Image Source, która tworzy takie same obrazy źródłowe, i wskazać katalog zawierający naszą aplikację oraz MSI.
  5. Nacisnąć OK. Jeśli nie pojawił się błąd, połączenie zakończyło się sukcesem.

Uwaga! MSI i nasza własna aplikacja muszą być położone w tym samym miejscu, ponieważ w katalogu instalacyjnym na nośnikach instalacyjnych są tworzone podkatalogi, do których kopiowane są pliki źródłowe pakietu MSM.

Po zakończeniu przyłączania należy upewnić się, że:

  1. Nie zostały zgłoszone błędy dotyczące konfliktu połączenia.
  2. Sygnatura MSM została dodana do tabeli sygnatur modułów (Modulesignature table) w MSI.
  3. Komponenty MSM zostały dodane do tabeli komponentów (Components table) w MSI.

Kiedy już wszystkie moduły zostały dodane, ponownie należy dokładnie sprawdzić poprawność działania instalacji na testowym komputerze, aby upewnić się, że nasz program instalacyjny zadziała prawidłowo.

Łączenie oparte na skryptach

Proces opisany w poprzednim rozdziale może być wykonany za pomocą skryptu. Ten sposób łączenia jest dostępny we wcześniejszych wersjach Orca, które nie posiadają UI.

Główne polecenie jest następujące:

c:\Progra~1\Orca\orca.exe /q /c /l %LogFile% /f %Feature% /m %MergeModule% c:\myAppPath\myApp.msi

gdzie:

  • q oznacza quit mode,
  • c oznacza dołączenie do bazy, jeśli nie wystąpił błąd,
  • l oznacza logowanie,
  • f oznacza cechę, do której moduł jest przyłączany,
  • m oznacza nazwę merge modułu.

Każdy moduł musi być dołączany do MSI przy użyciu takiej linii komend. Domyślnie uruchomienie Orca w linii komend nie powoduje logowania ani zgłaszania błędów. Dlatego ważne jest używanie przełącznika /l, aby móc zobaczyć ewentualne komunikaty o błędach. Zmiany nie są zapisywane w bazie, jeśli wystąpi krytyczny błąd. Można również wykonać kroki 2. i 3. procesu weryfikacji, opisane w Technikach łączenia, aby sprawdzić wynik połączenia.

Uruchomienie programu instalatora

Kliknięcie na pakiet MSI spowoduje uruchomienie programu instalatora i, jeśli wszystko pójdzie dobrze, aplikacja i MSDE 2000 zostaną zainstalowane.

W czasie łączenia modułów MSDE 2000 z własną aplikacją po uruchomieniu programu Setup skrót do Service Managera nie zostanie utworzony automatycznie i jego ikona na pasku systemowym nie będzie widoczna. Takie zachowanie może być zdefiniowane jedynie w głównym pakiecie MSI, nie zaś w pakietach MSDE 2000. Mimo to Task Manager pokaże, że serwis jest uruchomiony, co oznacza, że instalacja się powiodła, a serwis wystartował. Service Manager może być przywołany za pomocą Sqlmangr.exe z katalogu Binn serwera SQL.

Czasami tabele muszą być tworzone i uzupełniane danymi podczas instalacji. Aby dokonać zmian w bazie danych, należy korzystać z bezpiecznego połączenia (takiego, które korzysta z autoryzacji Windows, a nie SQL Serwera) i uruchamiać MSI w skrypcie wraz z serią komend osql.

Wnioski

Łączenie MSDE 2000 z własną aplikacją jest procesem łatwym, zwłaszcza dzięki szerokim możliwościom edytora Orca. Używając narzędzi opisanych w tym artykule oraz stosując najświeższy service pack, w prosty sposób można osiągnąć zamierzony cel.

Dodatek A: Najczęściej zadawane pytania

Otrzymałem informację o błędzie, mówiącą, że wystąpił konflikt połączenia. Jak mam rozwiązać ten problem?

Błąd konfliktu połączenia podaje nazwę tabeli oraz wskaźnik rekordu, który wywołuje konflikt. Należy porównać tabelę z MSI oraz MSM i ujednolicić wartości w tych rekordach. Następnie ponowić próbę połączenia.

Czy muszę łączyć wszystkie moduły MSDE 2000? Słyszałem, że niektóre z nich są jedynie opcjonalne.

Można zredukować ilość miejsca zajmowanego przez naszą aplikację poprzez dostosowanie SQL Server 2000 Desktop Engine Setup, tak by nie instalował komponentów Serwera SQL 2000, które nie będą używane przez aplikację. Można opuścić DMO*.msm i/lub Repl*.msm. Są to moduły SQL-DMO i replikacji.

Wykonuję pojedyncze łączenie używając skryptu, ale nie otrzymuję komunikatów błędów.

Należy użyć przełącznika /l, aby wygenerować plik z logami. Więcej informacji we wcześniejszym paragrafie Łączenie oparte na skryptach.

Setup zakończył się pomyślnie, ale nie wiem, czy serwis wystartował.

Serwis startuje domyślnie. Task Manager pokaże, że serwis jest uruchomiony. Można uruchomić jakąkolwiek aplikację, która wymaga z nim połączenia, lub wykonać serię poleceń osql, aby sprawdzić pracę serwisu.

Kiedy instaluję MSDE 2000 z CD-ROM-u, widzę jego ikonę na pasku systemowym, jednak nie ma jej, kiedy MSDE 2000 jest osadzony w mojej aplikacji. Dlaczego?

Skróty są tworzone przez MSI (Sqlrun01.msi) z CD-ROM-u. Tworzenie skrótu nie jest wykonywane przez żaden z modułów, dlatego musi być umieszczone w głównym pakiecie MSI (patrz Tworzenie pakietu MSI). Aby zobaczyć ikonę na pasku, trzeba uruchomić Sqlmgr.exe z katalogu Binn SQL serwera.

Moja aplikacja nie może połączyć się z MSDE 2000. Dostaję komunikat, że połączenie, które usiłuję wykonać, nie jest połączeniem bezpiecznym. Jak mogę temu zaradzić?

To się zdarza, ponieważ MSDE 2000 używa autoryzacji Windows jako domyślnej, która jest bezpieczniejsza niż autoryzacja serwera SQL. Trzeba zmienić swoją aplikację tak, aby używała bezpiecznego logowania zamiast autoryzacji SQL. Można także zmienić domyślny sposób instalowania MSDE (modyfikując SECURITYMODE – parametr instalacji).

Nie jestem w stanie podać przykładowej nazwy ani zmienić trybu bezpieczeństwa, kiedy używam merge modułów. Czy w ogóle można to zrobić? Jeśli tak, to jak mogę zmieniać wewnętrzne właściwości?

Można dodać INSTANCENAME do tabeli właściwości i podać nazwę. W ten sam sposób można też dodać SECURITYMODE. Należy jednak pamiętać, że zmiany te muszą być wprowadzone w głównym pakiecie instalacyjnym, a nie w modułach SQL Server 2000 MSDE. Każdą z tych właściwości można zaplanować jako wewnętrzną właściwość merge modułu poprzez określenie odpowiedniego działania w głównym MSI. Więcej informacji w artykule PRB: Cannot Specify Instance Name Using SQL Server 2000 Merge Modules (Q281983).

Czasami pojawiają się w logach informacje o błędach, ale Setup działa prawidłowo. Dlaczego?

Błędy są generowane, gdy podczas łączenia w MSI i MSM zostaną wykryte identyczne rekordy. Dopóki są one wypisywane jedynie w logach, nie są błędami krytycznymi i mogą się zdarzyć. Jeśli zmiany są dokonywane tylko w bazie danych, nie należy się nimi przejmować.

Podczas wykonywania Setup otrzymuję następujący komunikat o błędzie: „Nie mogę pobrać ID pakietu”. Co się dzieje?

To się zdarza w wersji RTM MSDE 2000. Błąd ten może być spowodowany obecnością Sqlboot.dll wcześniejszej instalacji na lokalnym komputerze. Należy zmienić nazwę każdej kopii Sqlboot.dll, uruchomić ponownie Setup, i z powrotem zmienić nazwę DLL. Jeśli to się zdarzy podczas czystej instalacji, osadzenie modułu SP1 powinno rozwiązać problem. SQL Server 2000 SP1 można ściągnąć ze strony Microsoft SQL Server: Downloads.

Czasem moja instalacja cofa się pod koniec wskaźnika postępu instalacji bez podania komunikatu o błędzie.

Trzeba sprawdzić logi. Może to być związane z instalacją monitora postępu (Installperformon). Osadzenie modułu SP1 MSDE 2000 powinno rozwiązać ten problem.

Jakiś czas temu zainstalowałem moją aplikację, a teraz chciałbym ją uaktualnić. Jak to zrobić?

Można uaktualnić aplikację jedynie poprzez uruchomienie pakietu uaktualniającego .msi. Więcej informacji − zobacz Windows Installer SDK. Instalacja MSDE może pozostać nietknięta.

Próbuję połączyć pakiety MSM, ale nic się nie dzieje: żadnych błędów, żadnych komunikatów, żadnej reakcji. Co jest przyczyną?

Prawdopodobnie Mergemod.dll nie jest zarejestrowany. Należy zarejestrować Mergemod.dll, używając regsrvr32 i ponowić próbę łączenia. Teraz powinno się udać.

Spis treści

Autor: Arulkumar Elumalai, Microsoft Corporation


Komentarze 0 Masz uwagi do tej strony? Napisz

Dodaj komentarz

avatar

Zaloguj się lub Zarejestruj się aby wykonać tę czynność.

Autor Jacek Kolonko
avatar VIP
 

What do you want to write today? ;)

Załóż konto
WSS to serwis, który łączy dziesiątki tysięcy specjalistów IT w Polsce, zajmujących się szeroko pojętymi technologiami Microsoft. Portal działa od 2003 roku, i oprócz setek publikacji technicznych, rozwijającego się forum - portal to ludzie, którzy go tworzą. To właśnie z myślą o nich warto codziennie nas odwiedzać.

Dowiedz się więcej o WSS

vGuru - Zostań Guru Wirtualizacji

 

MetroOne

Idź na górę strony