Leseprobe
Inhaltsverzeichnis
1
Einleitung
4
1.1
Das Client-Server-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.1
Einfacher Lesezugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2.2
Schreibzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2.3
Komplexe Transaktion . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.3
Vergleichskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.4
Technische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.4.1
HTTP: ein zustandsloses Protokoll . . . . . . . . . . . . . . . . . . . .
13
1.4.2
Der Urahn: das Common Gateway Interface (CGI) . . . . . . . . . . .
13
2
Active Server Pages
15
2.1
Vorstellung von Active Server Pages . . . . . . . . . . . . . . . . . . . . . . .
15
2.2
Die Sprache VBScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3
Datenbankzugriff mit ASP ¨
uber ADO . . . . . . . . . . . . . . . . . . . . . .
18
2.4
Realisierung der Aufgaben mit ASP
. . . . . . . . . . . . . . . . . . . . . . .
20
2.5
Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3
Oracle, Linux und Apache
28
3.1
Vorstellung von Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2
Die SuSE-Oracle Partnerschaft . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.3
Der HTTP-Server Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4
Die Skriptsprache PHP
31
4.1
Vorstellung von PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2
Die Sprache PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.3
Datenbankzugriff mit PHP
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.4
Realisierung der Aufgaben mit PHP . . . . . . . . . . . . . . . . . . . . . . .
34
4.5
Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5
Java auf dem Web-Server
40
5.1
Vorstellung von Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.2
Erkl¨
arung wichtiger Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.3
Datenbankzugriff mit Java: JDBC
. . . . . . . . . . . . . . . . . . . . . . . .
41
1
INHALTSVERZEICHNIS
2
5.4
Servlets mit Apache JServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.5
Servlets mit Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.5.1
Vorstellung von Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.5.2
Technik des Datenbankzugriffs mit Tomcat als Servlet-Container . . .
45
5.6
Realisierung der Aufgaben als Servlets . . . . . . . . . . . . . . . . . . . . . .
47
5.7
Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
6
Java auf dem Datenbank-Server
56
6.1
Vorstellung der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.2
Ein einf¨
uhrendes Beispiel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.3
Eine komplexere Funktion f¨
ur die Radl-Datenbank . . . . . . . . . . . . . . .
60
7
Sonstige M¨
oglichkeiten
62
7.1
WebDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
7.2
SQLJ
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
7.3
Java Server Pages mit Tomcat
. . . . . . . . . . . . . . . . . . . . . . . . . .
66
8
Zusammenfassung
70
8.1
Erweiterung des HTTP-Servers . . . . . . . . . . . . . . . . . . . . . . . . . .
70
8.2
Vergleichskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
8.3
Der Gewinner des Vergleichs
. . . . . . . . . . . . . . . . . . . . . . . . . . .
73
A Installation und Konfiguration
74
A.1 Active Server Pages unter Microsoft Windows . . . . . . . . . . . . . . . . . .
75
A.2 Oracle 8iR2 unter SuSE Linux 6.4
. . . . . . . . . . . . . . . . . . . . . . . .
75
A.3 Die Radl-Datenbank unter Oracle . . . . . . . . . . . . . . . . . . . . . . . . .
78
A.4 PHP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
A.5 Java und JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
A.6 Apache JServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
A.7 Tomcat
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
A.8 Entwickeln von Servlets unter Tomcat . . . . . . . . . . . . . . . . . . . . . .
88
A.9 SQLJ
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
A.10 WebDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
Abbildungsverzeichnis
96
Tabellenverzeichnis
97
Literaturverzeichnis
98
Vorwort
Informationen geh¨
oren in unserem Zeitalter zu den wichtigsten G¨
utern. Bei jedem einzel-
nen Menschen werden sie zur Entscheidungs- und Wissensfindung herangezogen. Neben
B¨
uchern werden als Speichermedium f¨
ur diese Informationen in zunehmenden Maße vor
allem Datenbanken eingesetzt. Dabei besteht der Wunsch, von ¨
uberall und zu jeder Zeit
Zugriff auf Datenbanken zu erlangen. Mit der Verbreitung des Internets kommt man die-
sem Ziel einen Schritt n¨
aher, indem Datenbankzugriffe ¨
uber das Internet realisiert werden.
Die dabei bestehenden M¨
oglichkeiten vorzustellen und zu vergleichen, ist das Thema dieser
Diplomarbeit.
3
Kapitel 1
Einleitung
1.1
Das Client-Server-Prinzip
Client-Server-Architekturen bestehen in der Regel aus zwei Arten von Kommunikationspart-
nern. Informationsanbietende Server einerseits stellen Dienste zur Verf¨
ugung und warten auf
Anfragen. Clients andererseits nutzen die Dienste von Servern, indem sie Anfragen stellen.
Bei Datenbankzugriffen ¨
uber das Internet, deren Grundprinzip Abbildung 1.1 zeigt, sind
hingegen drei Komponenten beteiligt:
· Der Web-Browser ist die Software, welche dem Benutzer Internetinhalte pr¨asentiert.
1
· Der HTTP-Server ist eine Serversoftware, die Internetinhalte bereith¨alt und sie auf
Anfrage eines Web-Clients an diesen liefert.
· Das Datenbankmanagementsystem (DBMS) ist verantwortlich f¨ur die Speicherung von
Daten und abstrahiert den Zugriff darauf.
Ergebnis der
DB-Abfrage
Datenbankmanagement-
system
HTTP-Response
Web-Browser
HTTP-Request
DB-Abfrage
HTTP-Server
Abbildung 1.1: Grundprinzip von Datenbankzugriffen ¨
uber das Internet
1
Die am meisten eingesetzten Web-Browser sind der Netscape Communicator und der Microsoft Internet
Explorer.
4
KAPITEL 1. EINLEITUNG
5
Der Web-Browser agiert gegen¨
uber dem HTTP-Server als Client. Dabei ist dieser Client der
einzig aktive Partner, nur er ergreift die Initiative und fordert Informationen vom HTTP-
Server an. Der HTTP-Server seinerseits ist gegen¨
uber dem DBMS auch Client. Somit ist der
HTTP-Server also gegen¨
uber dem DBMS ein Client, gegen¨
uber dem Web-Browser ein Ser-
ver. Die drei Komponenten Web-Browser, HTTP-Server und Datenbankmanagementsystem
sind prinzipiell eigenst¨
andig und k¨
onnen auf physikalisch getrennten Computern laufen. Im
Rahmen der Untersuchungen f¨
ur diese Diplomarbeit steht nur ein Rechner zur Verf¨
ugung,
so dass Web-Browser, HTTP-Server und DBMS auf ein und demselben Rechner laufen.
Dies ¨
andert jedoch nichts an den Prinzipien, Abl¨
aufen oder Funktionsweisen. W¨
ahrend die
M¨
oglichkeiten der Kommunikation ¨
uber das Internet sich auf immer weitere Ger¨
ateklassen
erstrecken, wie beispielsweise auf Handys oder Personal Digital Assistants (PDAs), so soll
hier das Augenmerk auf die
"
klassische" Variante, n¨
amlich auf einen Web-Browser in Ver-
bindung mit einem Standard-PC als Client gerichtet werden. Beim Datenbankzugriff ¨
uber
das Internet spielen neben der Skript- bzw. Programmiersprache vor allem die Wahl des
DBMS sowie des HTTP-Servers eine wichtige Rolle. Welche Produkte hier zu w¨
ahlen sind,
ist durch die nachfolgend kurz dargelegte Aufgabenstellung der Diplomarbeit festgelegt.
1.2
Aufgabenstellung
Im Rahmen dieser Diplomarbeit werden folgende M¨
oglichkeiten zum Zugriff auf Datenban-
ken ¨
uber das Internet aufgezeigt:
· Zugriff auf eine Access-Datenbank ¨uber den Microsoft Internet Information Server
(IIS), bzw. den Microsoft Personal Web Server in Verbindung mit ADO-ASP (ActiveX
Data Objects - Active Server Pages).
· Zugriff auf eine Oracle-Datenbank mittels der Skriptsprache PHP
2
unter Linux.
· Zugriff auf eine Oracle-Datenbank mit serverseitigem Java unter Linux.
F¨
ur jede dieser drei Konfigurationen sind folgende Datenbankzugriffe zu realisieren:
1. Einfacher Lesezugriff
2. Schreibzugriff
3. Komplexe Transaktion
Die Radl-Datenbank
Als Beispieldatenbank wird die Radl-Datenbank aus [1] verwendet, welche im Folgenden als
bekannt vorausgesetzt wird. Alle Referenzen beziehen sich zwar auf [1]; die Radl-Datenbank
wird jedoch in der neueren Version verwendet, wie sie in der zweiten Ausgabe von [1] be-
schrieben ist. Zu beziehen ist die aktuelle Version der Radl-Datenbank (SQL-Skript) von [2].
Es folgt nun eine genaue Betrachtung der einzelnen Aufgaben.
2
PHP: PHP Hypertext Processor
KAPITEL 1. EINLEITUNG
6
1.2.1
Einfacher Lesezugriff
Nach der Herstellung einer Verbindung mit der Radl-Datenbank wird der Inhalt der Tabelle
Personal gelesen und als HTML-Tabelle ausgegeben. Der einfache Lesezugriff soll im We-
sentlichen aufzeigen, wie eine Datenbankverbindung erfolgt und wie mit einem mehrspaltigen
Ergebnis umzugehen ist.
Besonderheiten und Schwierigkeiten dieser Aufgabe
Als Erweiterung dieser Aufgabe soll mitverfolgt werden, wie oft Benutzer mit ihren Web-
Browsern das Auslesen der Tabelle Personal angefordert haben. Mit dieser Zusatzaufgabe
wird ¨
uberpr¨
uft, ob die jeweilige L¨
osung ¨
uber die F¨
ahigkeit verf¨
ugt, ein Objekt bzw. eine
Variable ¨
uber mehrere Client-Zugriffe hinweg zu behandeln. Dabei ist zu beachten, dass
der Z¨
ahler die tats¨
achliche Anzahl an Client-Zugriffen darstellt, also immun ist gegen sog.
Race-Conditions.
3
1.2.2
Schreibzugriff
Als Schreibzugriff wird die Preis¨
anderung eines Teiles implementiert. Dabei bekommt der
Benutzer als erstes eine Liste der vorhanden Teile zur Auswahl. Diese Liste entspricht der
Tabelle Teilestamm. Hat der Benutzer aus dieser Teileliste ein bestimmtes Teil ausgew¨
ahlt,
so bekommt er im zweiten Schritt den Preis dieses Teiles mitgeteilt und kann in einem
Eingabefeld einen Wert als neuen Preis f¨
ur dieses Teil festlegen. Im dritten Schritt wird die
Preis¨
anderung in der Datenbank durchgef¨
uhrt. Zur Kontrolle wird anschließend erneut der
Preis des jeweiligen Teiles von der Datenbank abgefragt und dem Benutzer angezeigt.
Besonderheiten und Schwierigkeiten dieser Aufgabe
Das Beispiel der Preis¨
anderung eines Teils zeigt unter anderem den Umgang mit HTML-
Formularen, sowie die in diesem Zusammenhang auftretende Parameter¨
ubergabe. Bei den
L¨
osungen dieser Aufgabe wird, da lediglich ein einzelner Schreibzugriff erfolgt, auf die Ver-
wendung von Transaktionsmechanismen verzichtet. Wie weiter unten zu sehen sein wird,
erfolgt zuerst ein Lesezugriff zur Ermittlung des Preises desjenigen Teiles mit einer be-
stimmten Teilenummer, im darauf folgenden Schreibzugriff wird dieser Preis aktualisiert
und zum Schluss mit einem weiteren Lesezugriff nochmals zur Kontrolle abgefragt. Da ins-
besondere die letzten beiden Zugriffe nicht durch einen Transaktionsmechanismus gesch¨
utzt
sind, k¨
onnte es passieren, dass aufgrund eines Request von Client A ein Schreibzugriff er-
folgt und noch vor dem abschließenden Kontroll-Lesezugriff ein Schreibzugriff von Client B
stattfindet. In diesem Fall erhielte Client A im Kontroll-Lesezugriff einen anderen Wert als
er vorher geschrieben hat. Die meisten Datenbanken setzen jedoch bei einem Schreibzugriff
einen sog. Lock auf das betreffende Tupel, so dass das oben beschriebene Problem nicht
auftreten kann. Durch diese Sperre sehen andere Datenbankverbindungen noch den alten
Wert und Schreibzugriffe werden auf dieses Tupel so lange blockiert, bis diejenige Daten-
bankverbindung, welche den Schreibzugriff ausf¨
uhrt, ein Commit oder Rollback durchf¨
uhrt.
3
Vgl. [6], Seite 57.
KAPITEL 1. EINLEITUNG
7
Client A bewirkt also mit dem Schreibzugriff eine Sperre des betreffenden Tupels, die auch
dann noch aktiv ist, wenn der Kontroll-Lesezugriff erfolgt. Dadurch erh¨
alt Client A beim
Kontroll-Lesezugriff garantiert den Wert, den er vorher geschrieben hat. Schreibzugriffe wei-
terer Clients werden blockiert, bis der Lock wieder aufgehoben ist. Dies ist dann der Fall,
wenn Client A die Verbindung zur Datenbank trennt. Dann wird n¨
amlich ein Auto-Commit
durchgef¨
uhrt. Auch Oracle versieht standardm¨
aßig von einem Schreibzugriff betroffene Tu-
pel mit einer Sperre.
4
Da der Schwerpunkt dieser Aufgabe darin besteht, einen einfachen
Schreibzugriff aufzuzeigen und Transaktionsmechanismen in Aufgabe 3 ausf¨
uhrlich vorge-
stellt werden, wird an dieser Stelle als gegeben vorausgesetzt, dass die Datenbank bei einem
Schreibzugriff einen Lock setzt. Als weitere Besonderheit wird im Rahmen dieser Aufgabe
gezeigt, wie eine ge¨
offnete Datenbankverbindung weitergereicht werden kann.
1.2.3
Komplexe Transaktion
Als Transaktion wird die Erfassung eines neuen Auftrags in der Radl-Datenbank realisiert.
Dieser bereits relativ komplexe Ablauf soll mit Hilfe von Abbildung 1.2 verdeutlicht werden.
Zun¨
achst werden vom Benutzer die notwendigen Daten zur Erfassung eines neuen Auftrags
gefordert. Hierzu geh¨
oren:
· Eingabe eines Datums
· Auswahl eines Kunden aus einer Liste aller in der Datenbank enthaltenen Kunden.
· Auswahl eines Mitarbeiters aus einer Liste aller in der Datenbank enthaltenen Mitar-
beiter.
· Angabe der Zahl der Bestellungen f¨ur jedes in der Tabelle Teilestamm enthaltenen
Teile.
Nach der Bet¨
atigung des Submit-Buttons
5
werden zuerst die Angaben einer ¨
Uberpr¨
ufung
unterzogen. Es muss ein Datum eingegeben worden sein, ein Kunde und ein Mitarbeiter aus-
gew¨
ahlt worden sein sowie mindestens eine Bestellung f¨
ur ein Teil vorliegen. Ebenso sind eine
Reihe von Sicherheitsabfragen zu realisieren, da der Benutzer bei der Angabe der Anzahl der
zu bestellenden Teile eine Reihe von Fehleingaben machen kann. Die Eingabe von negativen
Werten ist ebenso abzufangen wie beispielsweise die sinnlose Eingabe von Buchstaben oder
Sonderzeichen. Nur wenn alle Eingaben korrekt sind, werden die im Folgenden beschriebe-
nen Aktionen durchgef¨
uhrt. Als erstes wird f¨
ur den zu erfassenden Auftrag eine Auftrags-
nummer bestimmt. Nun wird in die Tabelle Auftrag ein neuer Eintrag, bestehend aus den
Informationen Auftragsnummer, Datum, Kundennummer und Personalnummer eingef¨
ugt.
Im Anschluss daran wird in einer Schleife ¨
uber alle Teile der in der ersten Seite ermittelten
Teileliste iteriert. Wenn f¨
ur das betreffende Teil des aktuellen Schleifendurchlaufs minde-
stens eine Bestellung vorliegt, sind eine Reihe weiterer Schritte notwendig. Dazu geh¨
oren
ein Eintrag in die Tabelle Auftragsposten sowie ein Eintrag in die Tabelle avo belegung, falls
zu dem betreffenden Teil ein Arbeitsvorgang exisitert. Schließlich muss ¨
uberpr¨
uft werden,
4
Siehe [1], Seite 223.
5
Schaltfl¨
ache zum Abschicken der Inhalte eines HTML-Formulars an den HTTP-Server
KAPITEL 1. EINLEITUNG
8
nein
ja
Datum eingegeben?
Wurde mindestens ein Teil bestellt?
ja
nein
Bestimmen einer neuen Auftragsnummer
Eintrag in Tabelle Auftrag
Wurde dieses Teil bestellt?
nein
Eintrag in Tabelle Auftragsposten
nein
ja
Eintrag in Tabelle avo_belegung
Besteht aktuelles Teil aus Einzelteilen?
ja
nein
Reservierung in Tabelle Lager
Anzeige eines Feldes zur Datumsabfrage
Ermittlung der Kundenliste und Anzeige zur Abfrage
Ermittlung der Mitarbeiterliste und Anzeige zur Abfrage
Ermittlung der Teileliste und Anzeige zur Abfrage
Benutzer gibt Datum ein, wählt Kunde, Mitarbeiter und Teile und drückt Submit-Button
Für alle Teile der Teileliste
Für jedes Einzelteil
Exisitiert für das aktuelle Teile ein Arbeitsvorgang?
Eintrag in Tabelle Teilereservierung
Reservierung in Tabelle Lager
Eintrag in Tabelle Teilereservierung
ja
Abbildung 1.2: Struktogramm zur Erfassung eines neuen Auftrags in der Radl-Datenbank
KAPITEL 1. EINLEITUNG
9
ob das Teil aus mehreren Einzelteilen zusammengesetzt ist. Ist dies nicht der Fall, so werden
f¨
ur das Teil selbst Eintragungen in die Tabellen Teilereservierung und Lager vorgenommen,
ansonsten erfolgen diese Eintragungen f¨
ur die Einzelteile.
Besonderheiten und Schwierigkeiten dieser Aufgabe
Drei Besonderheiten treten bei der Realisierung dieser Aufgabe zu Tage, n¨
amlich das St¨
uck-
listenproblem, die Weitergabe von Datenbankabfrage-Ergebnissen sowie der Umgang mit
Transaktionen.
Das St¨
ucklistenproblem:
Die Radl-Datenbank krankt wie viele andere relationale Da-
tenbanken auch an dem sog. St¨
ucklistenproblem. Die Teile der Relation Teilestamm
bestehen in vielen F¨
allen aus mehreren anderen Teilen. Diese Einzelteile k¨
onnen ih-
rerseits wieder aus anderen Teilen zusammengesetzt sein und so weiter. Es handelt
sich also um rekursive Abh¨
angigkeiten. Alle diese Teile sind in der Relation Teile-
stamm enthalten, die Struktur der Teile muss bei relationalen Datenbanken in einer
separaten Tabelle abgebildet werden; im Falle der Radl-Datenbank handelt es sich
hier um die Tabelle Teilestruktur. Bei der Erfassung eines neuen Auftrags im Zuge
der Realisierung einer komplexen Transaktion wird das St¨
ucklistenproblem tangiert.
Beispielsweise muss bei einer Bestellung des Artikels Herren-City-Rad in der Tabel-
le Teilereservierung nicht dieser eine Artikel reserviert werden, sondern es m¨
ussen
diejenigen Teile reserviert werden, aus denen sich der Artikel zusammensetzt. Falls
diese Teile wiederum aus weiteren Einzelteilen zusammengesetzt sind, so w¨
are auch
hier entsprechend zu verfahren. Entsprechende Probleme ergeben sich auch bei der
Relation avo belegung. Diese rekursiven Abh¨
angigkeiten w¨
urden den Programmcode
kompliziert machen, ohne einen Beitrag zum Aufzeigen der Techniken des Datenbank-
zugriffs ¨
uber das Internet zu machen. Aus diesem Grunde wird auf das vollst¨
andige
Verfolgen aller Rekursionsebenen verzichtet und stattdessen nur eine Rekursionsebene
des St¨
ucklistenproblems beachtet.
Weitergabe eines Result-Sets:
Die Aufgabe des Erfassens eines neuen Auftrags wird
mit zwei ASP-, PHP- bzw. Java-Dateien erledigt. In der ersten Datei wird dem User
eine Liste aller Teile der Tabelle Teilestamm gezeigt, in welche er die Anzahl der Be-
stellungen f¨
ur jedes Teil eintr¨
agt. In der zweiten Datei muss ¨
uber genau diese Liste
iteriert werden. W¨
urde nun in der zweiten Datei diese Liste erneut von der Datenbank
angefordert, so k¨
onnte sie sich in der Zwischenzeit bereits ge¨
andert haben. Von einer
anderen Stelle k¨
onnte ein Teil aus der Tabelle Teilestamm entfernt oder hinzugef¨
ugt
worden sein. Eine L¨
osung dieses Problems w¨
are, in der ersten Datei die Tabelle Teile-
stamm komplett (nicht nur ein einzelnes Tupel) zu locken, die Teileliste anzufordern,
in der zweiten Datei die Teileliste erneut anzufordern und erst danach den Lock wieder
freizugeben. Diese L¨
osung h¨
atte jedoch einige gravierende Schwachstellen. Erstens ist
es nicht ratsam, eine komplette Tabelle zu locken. Zweitens w¨
urde dieser Lock relativ
lange dauern, schließlich braucht der Benutzer eine geraume Zeit zum Eingeben aller
Daten, die zur Erfassung eines neuen Auftrags notwendig sind. Aus diesem Grund wird
KAPITEL 1. EINLEITUNG
10
die Teileliste nur in der ersten Datei angefordert und dann mittels einer Session an die
zweite Datei ¨
ubergeben.
Transaktionsmechanismus:
F¨
ur die Zugriffe zur Erfassung eines neuen Auftrags in der
Radl-Datenbank gilt folgende Regel: Es m¨
ussen entweder alle Zugriffe durchgef¨
uhrt
werden oder aber keine von ihnen. Das Erfassen eines neuen Auftrags stellt also eine
Transaktion dar. Schl¨
agt ein Zugriff zur Erfassung eines neuen Auftrags fehl, so sind
alle bis dahin erfolgten (Schreib)-Zugriffe r¨
uckg¨
angig zu machen.
1.3
Vergleichskriterien
Aus den zu realisierenden Datenbankzugriffsbeispielen (einfacher Lesezugriff, Schreibzugriff,
komplexe Transaktion) leiten sich folgende Kriterien ab, nach denen die M¨
oglichkeiten zum
Zugriff auf Datenbank zu bewerten und zu vergleichen sind:
Transaktionen
Der Transaktionsmechanismus spielt eine entscheidende Rolle in Verbindung mit Datenbank-
zugriffen. Eine Transaktion ist eine Gruppe von Datenbank-Schreibzugriffen, die entweder
alle durchgef¨
uhrt werden oder keiner von ihnen.
6
Fehlerbehandlung
Bei der Programmierung ist zu ber¨
ucksichtigen, dass jeder Zugriff auf eine Datenbank einen
Fehler hervorrufen kann, weswegen die Formulierung der Fehlerbehandlung in der jeweiligen
Programmiersprache sehr wichtig ist. Durch das Zusammenspiel der drei Komponenten,
Web-Browser, HTTP-Server und DBMS k¨
onnen eine Reihe von Fehlern auftreten:
· St¨orung oder Unterbrechung der Netzwerkverbindung zwischen Web-Browser und
HTTP-Server
· St¨orung oder Unterbrechung der Netzwerkverbindung zwischen HTTP-Server und
DBMS
· Fehler im HTTP-Server
· Fehler im DBMS
· Verletzung von Integrit¨atsregeln
· Fehlerhafte Benutzereingaben
6
Vgl. [1], Kapitel 8.
KAPITEL 1. EINLEITUNG
11
Sessions
Wie weiter unten beschrieben ist, verf¨
ugt das HTTP-Protokoll, welches der Kommunika-
tion zwischen dem Web-Browser und dem HTTP-Server dient, nicht ¨
uber Zust¨
ande, es
ist zustandslos. Bei Web-Anwendungen ist es jedoch in sehr vielen F¨
allen notwendig, mit
Zust¨
anden wie beispielsweise Usernamen, Datenbankverbindungen oder vom User getroffe-
nen Auswahlen, umzugehen. Da nun das HTTP-Protokoll solche M¨
oglichkeiten nicht zur
Verf¨
ugung stellt, wird die Zustandsverfolgung von einem HTTP-Server mittels sog. Sessions
¨
ubernommen. Eine Session ist die Verbindung zwischen einem bestimmten Web-Browser und
dem HTTP-Server. Sessions sind Client-bezogen, insbesondere nicht nur auf einen Rech-
ner oder Benutzer, sondern auf ein einzelnes Fenster des Web-Browsers eines Benutzers.
Auf Session-Objekte k¨
onnen also prinzipbedingt keine konkurrierenden Zugriffe erfolgen.
Ein wichtiges Anwendungsbeispiel von Sessions ist die Weitergabe von Result-Sets. Session-
Objekte bzw. -Variablen werden im Server gehalten und nicht an den Client geschickt. Der
Client erh¨
alt lediglich bei Session-Beginn eine Session-ID, welche er bei jedem Zugriff inner-
halb der gleichen Session wieder an den Server zur¨
uckschickt. Somit kann der HTTP-Server
bestimmen, welche Session-Objekte zu welchem Client geh¨
oren. F¨
ur den Web-Client bzw.
den HTTP-Server gibt es zwei M¨
oglichkeiten mit Session-IDs umzugehen, n¨
amlich Cookies
oder URL
7
-Rewriting.
8
Es gilt nun zu untersuchen, ob Sessions m¨
oglich sind und ob diese
funktionieren. Desweiteren wird gepr¨
uft, welche Auswirkungen auf das Funktionieren von
Sessions die verschiedenen Cookie-Einstellungen des Web-Browsers haben, denn das Akzep-
tieren des Web-Browsers von Cookies kann vom User ein- bzw. ausgeschaltet werden.
Persistenz, Applikation
Unter Persistenz ist zu verstehen, dass Objekte ¨
uber mehrere Requests hinweg verwendet
werden k¨
onnen. Dabei werden die F¨
ahigkeiten von Sessions dahingehend erweitert, dass
der Umgang von Objekten oder Variablen ¨
uber Sessions hinweg m¨
oglich wird. Alle Clients,
Benutzer, Rechner haben Zugriff auf ein und dieselbe Variable oder auf das selbe Objekt.
Dabei stellt sich, wie in [6] auf Seite 57 beschrieben, das Problem konkurrierender Zugriffe.
Es wird daher untersucht, wie die jeweilige L¨
osung mit Session ¨
ubergreifenden Objekten
sowie dem Problem der konkurrierenden Zugriffe umgehen kann. In Verbindung mit ASP
wird gem¨
aß [3] f¨
ur Session-¨
ubergreifende Objekte der Begriff Applikation verwendet.
Der Umgang mit Datenbankabfrage-Ergebnissen
Das Ergebnis von Datenbankabfragen ist nur im einfachsten Fall ein einzelner Wert, in der
Regel handelt es sich um mehrspaltige und mehrzeilige Ergebnisse (Tabellen), die meist als
Result-Sets bezeichnet werden. Der Umgang mit diesen Result-Sets ist ein wichtiges Kriteri-
um zum Vergleich von Datenbankzugriffen. Die M¨
oglichkeiten reichen von einem einmaligen
zeilenweisen Lesen des Result-Sets bis hin zu Vor- und Zur¨
uckscrollen und beliebigem Po-
sitionieren. Manche Datenbankzugriffsm¨
oglichkeiten bieten sogar Result-Sets, die nicht nur
7
URL: Uniform Resource Locator
8
Weitere Informationen zu dem Themengebiet Sessions in Verbindung mit Cookies oder URL-Rewriting
finden sich in [3] in den Kapiteln 7 und 10.
KAPITEL 1. EINLEITUNG
12
gelesen, sondern auch beschrieben werden k¨
onnen und dadurch ein komfortableres Update
von Tabellen erm¨
oglichen als durch das Formulieren von SQL-Update-Anweisungen. Falls die
jeweilige Datenbankzugriffsm¨
oglichkeit solche Funktionalit¨
at bietet, wird davon Gebrauch
gemacht.
SQL Stored Prozedures
SQL Stored Prozedures erm¨
oglichen es, Programmcode direkt innerhalb eines DBMS
ausf¨
uhren zu lassen.
9
Bei der Radl-Datenbank ist es beim Erfassen eines neuen Auftrags
unter Umst¨
anden notwendig, in der Tabelle Lager die Anzahl der Reservierungen f¨
ur ein
bestimmtes Teil zu erh¨
ohen. Dabei ist gegebenenfalls ein weiterer Update dieser Tabelle
n¨
otig, um den Z¨
ahler f¨
ur die Bestellungen dieses Teiles zu erh¨
ohen. Da auf eine Datenbank
mehrere verschiedene Anwendungsprogramme zugreifen, besteht die Gefahr, dass eines die-
ser Programme das Handling der Reservierungen und Bestellungen fehlerhaft durchf¨
uhrt. Es
ist daher besser, wenn solche Aktionen direkt in der Datenbanksoftware geschehen. Dabei
geht es nicht um Inkonsistenzen im Sinne einer relationalen Datenbank, sondern um Fehler in
der Business-Logik. SQL Stored Prozedures sind mit Triggern verwandt, welche automatisch
von der Datenbanksoftware bei bestimmten Zugriffen auf eine Tabelle ausgef¨
uhrt werden.
SQL Stored Prozedures gehen jedoch ¨
uber die Funktionalit¨
at von Triggern hinaus, sie bie-
ten die Sprachkonstrukte einer Programmiersprache und k¨
onnen im Gegensatz zu Triggern
auch R¨
uckgabewerte an die aufrufende Applikation zur¨
uckgeben. Ein weiterer Unterschied
ist, dass Trigger implizit aufgerufen werden, SQL Stored Prozedures hingegen explizit. Es
wird untersucht, ob SQL Stored Prozedures mit dem jeweiligen DBMS m¨
oglich sind und wie
sie bei der jeweiligen Datenbankzugriffstechnik eingesetzt werden k¨
onnen.
Einbettung in HTML
Ein weiteres Vergleichskriterium stellt die Frage, wie die Verkn¨
upfung der Programmier-
bzw. Skriptsprache mit HTML-Code gestaltet ist.
9
Im Gegensatz dazu laufen
"
gew¨
ohnliche" Skripte und Programme zum Datenbankzugriff auf dem HTTP-
Server.
KAPITEL 1. EINLEITUNG
13
1.4
Technische Grundlagen
1.4.1
HTTP: ein zustandsloses Protokoll
Das HTTP-Protokoll dient bei Datenbankzugriffen ¨
uber das Internet der Kommunikation
zwischen dem Web-Browser und dem HTTP-Server. Der Web-Browser sendet einen HTTP-
Request an den HTTP-Server. Ein solcher Request ist im einfachsten Fall die Anforde-
rung einer HTML-Seite. Der HTTP-Server sucht die angeforderte HTML-Seite und schickt
sie in einem HTTP-Response an den Client (Browser) zur¨
uck. Das HTTP-Protokoll kennt
nur solche Request/Response-Paare. Nach der Ausf¨
uhrung eines Response werden keiner-
lei Informationen ¨
uber einen solchen Vorgang gespeichert, insbesondere k¨
onnen also keine
Daten zwischen verschiedenen Request/Response-Paaren ausgetauscht werden. Aus diesem
Grund wird HTTP auch als
"
zustandsloses" Protokoll bezeichnet. Die Initiative zur Anfor-
derung von Informationen geht beim HTTP-Protokoll immer vom Client aus. Im Rahmen
von Datenbankzugriffen ¨
uber das Internet bedeutet dies, dass letztendlich nur der Web-
Browser eine Datenbankabfrage anstoßen kann. Das Ergebnis der Datenbankabfrage wird
dann in der Regel einmalig dem Benutzer angezeigt. Wenn sich der entsprechende Wert in
der Datenbank nun ver¨
andert, so hat ein Standard-HTTP-Server keine M¨
oglichkeit, ¨
uber
das HTTP-Protokoll einen Web-Browser davon in Kenntnis zu setzen. Aus diesem Grund
und aufgrund der Tatsache, dass das Ergebnis einer Datenbankabfrage durch das Internet
unter Umst¨
anden eine relativ lange Zeit ben¨
otigt, um vom HTTP-Server zum Web-Browser
zu gelangen, kann es bei Nichtbenutzung von Transaktionsmechanismen geschehen, dass ein
Datenbankeintrag zu dem Zeitpunkt, an dem er beim Web-Browser ankommt, in der Daten-
bank bereits nicht mehr aktuell ist. In der Zeit, in der das Ergebnis einer Datenbankabfrage
n¨
amlich vom HTTP-Server zum Web-Browser ¨
ubertragen wird, k¨
onnen bereits andere Cli-
ents die betreffenden, nicht durch Locks oder Transaktionen gesch¨
utzten Tupel oder Tabellen
beschreiben.
1.4.2
Der Urahn: das Common Gateway Interface (CGI)
Die in dieser Arbeit vorgestellten M¨
oglichkeiten zum Zugriff auf Datenbanken sind in Ab-
grenzung bzw. als bessere M¨
oglichkeiten als die Benutzung der CGI-Schnittstelle zu be-
trachten. CGI stellt einen Mechanismus bereit, durch den ein Web-Browser das Ausf¨
uhren
eines Programmes auf dem Web-Server ausl¨
osen kann. Dies war der erste Schritt von sta-
tischen zu dynamischen Internetinhalten. Problematisch bei der CGI-Schnittstelle ist je-
doch die umst¨
andliche Handhabung und Konvertierung von Parametern und Daten zwi-
schen dem sog. CGI-Programm und den HTML-Anfragen bzw. -Antworten. Ein weiterer
großer Nachteil ist, dass f¨
ur jede Client-Anfrage an ein CGI-Programm ein eigenst¨
andiger
Prozess im Web-Server erzeugt werden muss, in dem das CGI-Programm abl¨
auft.
10
Das
CGI-Programm enth¨
alt per Standardeingabe die Parameter und deren Werte. Alle Daten,
die das CGI-Programm ¨
uber die Standardausgabe weitergibt, werden an den HTTP-Server
weitergeleitet, der sie an den Web-Browser zur¨
ucksendet. Das CGI-Programm kommuniziert
also nicht mit dem Web-Browser, sondern lediglich mit dem HTTP-Server. Dies bedeutet
10
In [6], Kapitel 2, wird beschrieben, welch großen Aufwand dies aus Sicht des Betriebssystems darstellt.
KAPITEL 1. EINLEITUNG
14
insbesondere, dass das CGI-Programm sich nicht um die Abwicklung des HTTP-Protokolls
k¨
ummern muss.
HTTP-Server
CGI-Programm
CGI-Schnittstelle
Web-Browser
Abbildung 1.3: Die CGI-Schnittstelle
Kapitel 2
Active Server Pages
2.1
Vorstellung von Active Server Pages
Beim Zugriff auf eine Access-Datenbank unter Microsoft Windows kommen die sog. Active
Server Pages (ASP) zum Einsatz. ASP ist eine weitverbreitete Technologie von Microsoft
zur Gestaltung von dynamischen Web-Applikationen.
Von CGI ¨
uber ISAPI zu ASP
Um den Nachteil zu umgehen, dass f¨
ur jede Client-Anfrage an ein CGI-Programm ein ei-
genst¨
andiger Prozess im Web-Server erzeugt werden muss, f¨
uhrte Microsoft die ISAPI
1
-
Schnittstelle ein. ISAPI st¨
utzt sich auf DLLs
2
, die bei der ersten entsprechenden An-
frage in den Prozessraum des HTTP-Servers geladen werden und dort verbleiben. Dies
bringt ab der zweiten Anfrage einen entscheidenden Performancevorteil gegen¨
uber der CGI-
Schnittstelle. ISAPI erm¨
oglicht die Entwicklung von Applikationen und Filtern. W¨
ahrend
ISAPI-Applikationen (bzw. die entsprechenden DLLs) nur auf explizite Anfrage eines Clients
ablaufen, werden ISAPI-Filter bei jeder Client-Anfrage aktiv. Durch die Verwendung von
ISAPI-Filtern k¨
onnen somit die F¨
ahigkeiten des HTTP-Servers erweitert werden. Die Funk-
tionalit¨
at von Activer Server Pages ist in einer einzigen DLL zusammengefasst (ASP.DLL).
Diese DLL ist ein ISAPI-Filter und befindet sich zur Laufzeit im gleichen Prozessraum wie
der HTTP-Server. Das Zusammenspiel von Web-Browser und HTTP-Server in Verbindung
mit der ASP-Technologie verdeutlicht Abbildung 2.1.
1
ISAPI: Internet Server Application Programming Interface
2
DLL: Dynamic Link Library
15
KAPITEL 2. ACTIVE SERVER PAGES
16
Internet
Information
Server
ASP ISAPI-DLL
Skriptsprachen-DLL
1
2
3
4
5
gleicher Prozessraum
Web-Client
Abbildung 2.1: ASP
1. Ein Web-Browser fordert ein *.asp-Dokument an.
2. Wie bei jeder Anfrage wird die ASP-ISAPI-DLL aktiv.
3. ASP l¨
adt notwendige Skriptsprachen DLLs in den Prozessraum des HTTP-Servers und
interpretiert den ASP-Code.
4. Das Ergebnis wird an den HTTP-Server zur¨
uckgegeben.
5. Der HTTP-Server schickt die Antwort (bestehend aus statischen und dynamischen
Teilen) an den Client.
Server
Application
Session
Request
Response
ASPError
ObjectContext
Tabelle 2.1: ASP-Objekte
ASP wird von folgenden, in HTML-Seiten eingebetten Skriptsprachen unterst¨
utzt:
· PerlScript
· JavaScript
· JScript
· VBScript (Visual Basic, Scripting Edition)
PerlScript basiert auf der vor allem in Verbindung mit Unix-Systemen beliebten Skriptspra-
che Perl.
3
JavaScript wird oft auch auf Client-Seite zum Ausf¨
uhren von Programmen inner-
halb des Web-Browsers verwendet. Es verf¨
ugt ¨
uber eine ¨
ahnliche Syntax wie Java, hat aber
3
Perl: Practical Extraction Language
KAPITEL 2. ACTIVE SERVER PAGES
17
ansonsten nichts mit Java zu tun. JScript ist eine Microsoft-eigene Version von JavaScript.
Es ist JavaScript ¨
ahnlich, aber nicht identisch damit. VBScript basiert auf Visual Basic und
ist eine abgespeckte Version von Visual Basic for Applications. VBScript unterst¨
utzt von
diesen Skriptsprachen am Besten den Zugriff auf ActiveX-Komponenten, weshalb die Wahl
auf diese Skriptsprache f¨
allt.
Applications und Sessions
ASP-Seiten werden automatisch in sog. Applikationen organisiert. Zu einer ASP-Applikation
geh¨
oren alle Dateien eines (virtuellen) HTTP-Server-Verzeichnisses, inkl. aller Unterver-
zeichnisse. Es k¨
onnen globale Variablen definiert werden, die entweder von allen Usern einer
ASP-Applikation geteilt werden oder von allen ASP-Seiten einer User-Session. Die Definiti-
on von globalen Variablen sowie die Angabe, ob lediglich innerhalb einer Session oder von
allen Clients darauf zugegriffen werden kann, erfolgen in der Datei global.asa.
2.2
Die Sprache VBScript
Im Rahmen dieser Diplomarbeit wird die ASP-Technologie anhand der in HTML-Seiten
eingebetten Skriptsprache VBScript aufgezeigt. Um dem HTTP-Server mitzuteilen, dass
VBScript als Skriptsprache verwendet wird, muss die erste Zeile einer solchen *.asp-Seite
folgendermaßen lauten:
<%@ LANGUAGE = "VBSCRIPT" %>
Wie bei den meisten Skriptsprachen, so sind auch bei VBScript alle Variablen typlos
und m¨
ussen standardm¨
aßig nicht deklariert werden. Durch die Verwendung der Anweisung
Option Explicit kann die Notwendigkeit der Variablendeklaration erzwungen werden. F¨
ur
gr¨
oßere Projekte ist dies sehr empfehlenswert, weil auf diese Weise Fehler leichter gefun-
den werden k¨
onnen. Etwas ungew¨
ohnlich bei VBScript ist, dass Anweisungen nicht durch
"
;" abgeschlossen werden m¨
ussen. Um eine Unterscheidung zwischen VBScript-Code und
HTML-Code zu erm¨
oglichen, wird VBScript-Code so in HTML-Seiten eingebunden:
<%
'VBScript-Code
%>
Wie bereits im obigen Code-Ausschnitt zu sehen ist, wird eine Kommentarzeile durch Vor-
anstellen von
"
'" vor die betreffende Zeile markiert. Um Datenbankzugriffe in Verbindung
mit ASP zu realisieren, werden meist die im folgenden Abschnitt beschriebenen Active X
Data Objects (ADO) verwendet. Im Zusammenspiel mit VBScript ist darauf zu achten, bei
der Zuweisung von Objekten, also auch der Active X Data Objects, vor die Zuweisung das
Kommando
"
set" zu stellen. Bei der Zuweisung von primitiven Datentypen in VBScript
entf¨
allt dieses Kommando.
KAPITEL 2. ACTIVE SERVER PAGES
18
2.3
Datenbankzugriff mit ASP ¨
uber ADO
Die ASP-Technologie bietet lediglich die Grundlage zum Ausf¨
uhren von Programmen auf
dem HTTP-Server. Um nun dem HTTP-Server den Zugriff auf Datenbanken zu erm¨
ogli-
chen, kommt eine weitere Technologie von Microsoft ins Spiel, die Active X Data Objects,
kurz ADO genannt.
4
Microsoft verfolgt die sogenannte Universal Data Access-Strategie.
5
Darunter ist die Erm¨
oglichung des Zugriffs auf Daten, die sich an beliebiger Stelle in einem
Unternehmen befinden, zu verstehen. Das wichtigste dabei ist, dass der Zugriff unabh¨
angig
von der Programmiersprache ist. Das Produkt, in welches die Universal Data Access Strate-
gie eingebunden ist, tr¨
agt den Namen Microsoft Data Access Components SDK und enth¨
alt
folgende Bestandteile:
Active X Data Objects (ADO):
Eine Sammlung von COM-Komponenten, die dem An-
wendungsentwickler Zugriff auf Daten ¨
uber einen sog. OLE DB Provider erm¨
oglichen.
OLE DB:
Eine Sammlung von low-level Programmierschnittstellen, welche Daten per
COM
6
bereitstellt. Der Zugriff auf Daten ¨
uber OLE DB ist abh¨
angig von der Da-
tenquelle.
Open Database Connectivity (ODBC):
Eine C-Schnittstelle zum Zugriff auf Daten
verschiedener Datenbankmanagementsysteme.
Auf ADO-Komponenten kann von einer Vielzahl von Programmier- und Skriptsprachen zu-
gegriffen werden, nicht nur ¨
uber ASP und VBScript. Wie in [3] beschrieben, setzt ADO auf
OLE DB auf. ODBC hingegen ist in die gleiche Ebene wie OLE DB einzuordnen. ODBC
stellt den kleinsten gemeinsamen Nenner zum Zugriff auf Datenbanken dar. Es wird nur ein
Funktionsumfang zur Verf¨
ugung gestellt, der von allen Datenbanken, f¨
ur welche es einen
ODBC-Treiber gibt, unterst¨
utzt wird. Dadurch gehen die Besonderheiten einiger Daten-
banken verloren, Kompatibilit¨
at geht also zu Lasten von Funktionalit¨
at. OLE DB stellt
mit seinen low-level Programmierschnittstellen hingegen auch die Besonderheiten einzelner
Datenquellen zur Verf¨
ugung. Hier kann es jedoch geschehen, dass eine Applikation Beson-
derheiten einer Datenbank verwendet, welche beim Einsatz einer neuen Datenbank nicht
mehr unterst¨
utzt werden. Die Active X Data Objects bestehen aus folgenden Komponen-
tengruppen:
ADO:
Die meistgenutzte Komponentengruppe. Durch ADO-Komponenten wird es Client-
Applikationen erm¨
oglicht, Zugriff auf Daten ¨
uber einen OLE DB provider zu erhalten.
Remote Data Services (RDS):
Durch RDS k¨
onnten Daten vom Server zum Client ge-
holt, dort manipuliert und anschließend wieder an den Server zur¨
uckgeschickt werden.
ADOX:
ADOX (Active X Data Objects Extensions for Data Definition Language and
Security) enth¨
alt Objekte, die den Zugriff auf Sicherheitsfunktionen erlauben.
4
Sehr gute Informationen zum Thema ADO finden sich in [3].
5
Vgl. [3], Kapitel 12.
6
COM: Component Object Model, eine sog. Komponententechnologie von Microsoft.
KAPITEL 2. ACTIVE SERVER PAGES
19
Active X Data Objects Multidimensional (ADO MD):
Eine Erweiterung von ADO
zum Zugriff auf multidimensionale Daten.
Zur Verwendung von ADO sind f¨
ur den Applikationsentwickler folgende beiden Dateien
relevant:
msado15.dll:
Diese Datei ist die Dynamic Link Library (DLL) f¨
ur die ADO COM-Objekte.
adovbs.inc:
Diese Datei enth¨
alt VBScript-Deklarationen f¨
ur alle Konstanten, welche von
msado15.dll verwendet werden. Zum Gebrauch dieser Konstanten kann diese Datei in
eigene Skripte eingebunden werden. Es sind entsprechende Include-Files auch f¨
ur die
Programmiersprachen C/C++ sowie Java vorhanden.
Command
Connection
Error
Field
Parameter
Property
Record
Recordset
Stream
Tabelle 2.2: ADO-Objekte
KAPITEL 2. ACTIVE SERVER PAGES
20
2.4
Realisierung der Aufgaben mit ASP
In der Konfigurationsdatei global.asa werden globale Variablen f¨
ur ASP-Applikationen und
Sessions definiert. F¨
ur die im Folgenden beschriebenen Zugriffe auf die Radl-Datenbank
verf¨
ugt diese Datei ¨
uber die Eintr¨
age:
<OBJECT RUNAT=Server SCOPE=Session ID=conn1 PROGID="ADODB.Connection">
</OBJECT>
<OBJECT RUNAT=Server SCOPE=Session ID=teileliste PROGID="ADODB.Recordset">
</OBJECT>
<SCRIPT LANGUAGE = "VBScript" RUNAT = Server>
Sub Session_OnStart
strConn = "Provider=Microsoft.Jet.OLEDB.4.0;
Data Source=\inetpub\wwwroot\me\radl\Radl.mdb"
conn1.Open strConn
End Sub
Sub Session_OnEnd
conn1.Close()
End Sub
</SCRIPT>
<SCRIPT LANGUAGE = "VBScript" RUNAT = Server>
Sub Application_OnStart
Application("counter") = 0
End Sub
</SCRIPT>
Es werden also zwei Objekte definiert: ADODB.Connection und ADODB.Recordset. Bei
dem Start einer Session wird eine Verbindung zur Radl-Datenbank aufgebaut, bei Session-
Ende wird diese Datenbankverbindung wieder abgebaut. Es sei nicht verschwiegen, dass
dieses Verfahren in Verbindung mit ODBC nicht die optimale Performance bringt, da hier-
durch das ODBC-Connection-Pooling nicht wirksam werden kann. Zum Aufzeigen dieser
M¨
oglichkeit wird also auf die optimale Performance in Verbindung mit ODBC verzichtet.
Der Vorteil der vorgestellten Methode besteht darin, dass die einzelnen ASP-Seiten bereits
eine Datenbankverbindung vorfinden und sich zudem nicht um das Beenden der Datenbank-
verbindung k¨
ummern m¨
ussen. Zus¨
atzlich zu den beiden ADODB-Objekten wird in global.asa
die Applikations-Variable counter definiert und bei Applikations-Start auf
"
0" gesetzt. Auf
diese Variable haben alle ASP-Seiten der Applikation Zugriff. Benutzt wird diese Variable,
um die Anzahl der Zugriffe auf die Datei simple.asp zu z¨
ahlen.
Ende der Leseprobe aus 101 Seiten
- Arbeit zitieren
- Ludwig Mittermeier (Autor:in), 2001, Datenbankzugriffe über das Internet - Möglichkeiten und Vergleich, München, GRIN Verlag, https://www.grin.com/document/185628
Ähnliche Arbeiten
Kostenlos Autor werden
✕
Leseprobe aus
101
Seiten
Kommentare