Bereitstellung von Microsoft Access-Datenzugriffsseiten mittels Microsoft Windows Server-Technologien

  I Inhaltsverzeichnis  

  Kapitel 1 Einfüuhrung  

  Thematisierung Zielsetzung Aufbau der Ausarbeitung Anmerkungen zur formalen Gestaltung  

1.  Einführung Seite  

1.1  Datenbank-Managementsysteme (DBMS)  01

1.1.1  Datenmodelle (DM)  03

1.1.2  Client-Server Datenbankarchitektur  06

1.1.3  Verteilungsebenen eines Datenbanksystems  07

1.1.4  Three Tier-Architekturmodell für Microsoft Access-Datenzugriffsseiten  08

1.2  Begriffsdefinitionen  11

1.2.1  Data Access Pages (DAP) als Bestandteil von Microsoft Access  11

1.2.1.2  Historie  13

1.2.1.3  Technische Client-Voraussetzungen Kompatibilität  14

1.2.2  ActiveX Data Objects (ADO) Data Access Objects (DAO)  16

1.2.3  Office Web Components (OW)C  17

2.  Frontend-Softwarestruktur Seite  

2.1  DAP-Struktur  19

2.1.1  Access-Datenbankstruktur  19

2.1.2  DAP-Erstellung innerhalb lokaler Entwicklungsumgebung  21

2.1.2.1  HTML-Datenbestandteil für ADO-Datenbankzugriff  23

2.2  Access-Arbeitsgruppensicherheit  25

2.3  Webbrowser-Erweiterung um OWC  30

3.  Backend-Softwarestruktur Seite  

3.1  Microsoft Windows Server-OS  31

3.2  IIS-Webserver Konfiguration  33

3.2.1  SSL-Datenübertragung (HTTPS)  34

3.2.2  HTTP-Authentifizierung  37

3.2.2.1  ADS-integrierte Authentifizierung  37

3.2.2.2  Htaccess-Authentifizierung  38

3.3  ADO OLE DB-Providerarchitektur  40

3.4  Remote Data Services (RDS)  43

3.4.1  Funktionsweise softwareseitige Voraussetzungen  44

3.4.2  RDS-Serverkonfiguration  45

4.  Kooperation von Frontend Backendsoftware Seite  

4.1  Kollektive Wirkungsweise von Client Server-RDS  46

4.2  HTTP HTTPS-Anfragenverlauf an DAP  47

4.3  Sicherheitsaspekte der Kooperation  48

Thematisierung

Die vorliegende wissenschaftliche Ausarbeitung thematisiert den informationstechnischen Fachbereich der seitens Microsoft entwickelten Technologie »Microsoft Access-Datenzugriffsseiten« als Möglichkeit, Datenbankinhalte zentralisiert für Onlinezugriffe bereitzustellen. Diesbezüglich werden administrative Obliegenheiten respektive programmiertechnischer Gesichtspunkte aus Sichtweise der serverseitigen Bereitstellung obiger Technologie fokussiert ausgearbeitet.

Zielsetzung

Es soll dem Leser eine fachliche Einschätzung aus operativer Sichtweise, für die erfolgreiche Realisation einer Datenbankbereitstellung mittels Microsoft Access-Datenzugriffsseiten ermöglicht werden. Um einen erhöhten Realitätsbezug herzustellen, werden für ein exemplarisches Praxissystem die seitens einer deutschen Einzelunternehmung verwendeten Access-Datenzugriffsseiten vorgestellt. Diese verfolgt den Schwerpunkt des »Executive Search«, welcher Dienstleistungen im Rahmen der Besetzung von vakanten Führungspositionen in Unternehmungen umsetzt.

Aufbau der Ausarbeitung

o Mittels einer Einführung werden im ersten Kapitel informationstechnische Grundbegriffe in Bezug auf die Anwendung obiger Technologie charakterisiert.

o Innerhalb der folgenden beiden Kapitel werden administrativ erforderliche Operationen, differenziert in Frontend- sowie Backend-Softwarestruktur ausgearbeitet.

o Die anschließende Einbeziehung beider softwareseitiger Perspektiven wird in Bezug auf deren Kooperation sowie zu berücksichtigenden Sicherheitsaspekten dieser thematisiert.

o Innerhalb des fünften Kapitels werden anhand einer Praxisrealisation der Datenbankbereitstellung mittels Microsoft Access-Datenzugriffsseiten exemplarisch deren Anforderungen sowie praktische Funktions- und Wirkungsweisen innerhalb einer Mehrbenutzerumgebung ausgearbeitet.

o Es werden folglich strategisch, ökonomische Gesichtspunkte für die Anwendung obiger Technologie thematisiert.

o Die Schlussbetrachtung stellt die in sämtlichen vorherigen Kapiteln erarbeiteten Inhalte, in Form einer ergebnisorientierten Aufführung, zusammenfassend dar.

Anmerkungen zur formalen Gestaltung

Um den Lesefluss dieser wissenschaftlichen Ausarbeitung nicht unnötig zu beeinträchtigen, wurden umfangreichere Ausführungen sowie (meist auszugsweise dargestellte) Quelltexte innerhalb des Anhangs (III. Abbildungen / Tabellen / Quelltexte) aufgenommen.

Das vorliegende Dokument wurde in Form eines aktiven PDF-Dokuments verfasst, so dass eine Navigation innerhalb dieses mittels Hyperlinks erfolgen kann. Diese sind optisch von inhaltlich wissenschaftlichen Textbestandteilen mittels hellblaufarbiger, unterstrichener Schriftdarstellung abgegrenzt.

Fachbegriffe werden innerhalb dieser wissenschaftlichen Ausarbeitung ausschließlich wie folgt mittels Kurzform dargestellt, falls diese seitens der Autoren der verwendeten Literatur in explizit dieser abgekürzten, nachfolgend exemplarischen Form ersichtlich sind:

-Fachbegriff (FB)-

Eigens verwendete Abkürzungen des Verfassers, welche nicht zwangsweise Fachbegriffen entsprechen, werden wie folgt vorgenommen und dienen aufgrund häufiger Verwendung selbiger Begriffe lediglich der Textreduzierung: -Begriff (nachfolgend »B« bezeichnet)-

Aufgrund dieser einheitlichen Festlegung ist letztere Anwendung innerhalb von Kapitelüberschriften nicht vorzufinden. Zudem sind sämtliche, in abgekürzter Form verwendeten Begriffe obiger beider Festlegungen innerhalb des Abkürzungsverzeichnisses (VIII) separat aufgeführt.

Im Folgenden werden die Architektur respektive Funktionsweise von Datenbank-Managementsystemen, diesen gestellte Anforderungen, sowie in diesem Kontext der Begriff der Datenmodelle aufgezeigt.

1.1 Datenbank-Managementsysteme (DBMS)

DBMS ¹ basieren auf theoretisch entwickelten Datenmodellen (DM), welche komplexe Modellierungskonstrukte zur Verfügung stellen, um ein präzises, virtuelles Abbild realer, unternehmensbezogener Vorgaben divergenter Geschäftsprozesse generieren zu können. Bei dieser abstrahierenden Vorgehensweise wird auf relevante Ausschnitte der Realvorgaben fokussiert, so dass ein exaktes Abbild realer Bereichsvorgaben resultieren kann (als solches bezeichnete »Miniwelt«), um letztlich im Gesamtumfang der Anforderungen an die IT-Infrastruktur ² einer Unternehmung zur Realisierung ökonomischer Zielsetzungen des DBMS positiv beitragen zu können. ³ Hierbei gelten nachfolgende Anforderungen an die mittels des DBMS verwaltete(n) Datenbank(en) (DB) ⁴ : 5

⇒ Speicherung logisch verbundener Datenbestände

⇒ Redundanz-Minimierung ⇒ Abfrage-& Änderungsmöglichkeiten (Manipulationen) von Datenbeständen ⇒ Logische Unabhängigkeit der Datenbestände von ihrer physischen Struktur ⇒ Zugriffsschutz ⇒ Integrität ⁶ ⇒ Mehrbenutzerzugriff (engl. Concurrency) ⇒ Technische Zuverlässigkeit, Ausfallsicherheit, Kontrollierbarkeit

Die nachfolgende Abbildung 01 (S. 02) veranschaulicht die grundlegende Architektur eines DBMS, dessen Datenbankmanager das Kernstück bildet, indem dieser als zentrale Vermittlungsschnittstelle agiert.

¹ vgl. VIII. Abkürzungsverzeichnis, DBMS

^{2 vgl. VII. Definitionenverzeichnis, IT-Infrastruktur 3 vgl. IX. Literaturverzeichnis, Kemper, A., Eickler, A. (2004), S. 21 4 vgl. VII. Definitionenverzeichnis, Datenbank 5 vgl. IX. Literaturverzeichnis, Schicker, E. (2000), S. 50-54 6} vgl. VII. Definitionenverzeichnis, Integrität

Abb. 01: DBMS-Architekturübersicht ^{(Quelle: Anlehnung an Kemper, A., Eickler, A. (2004), S. 27)} Die Aufgabenbereiche eines DBMS begrenzen sich nicht auf die ausschließliche Umsetzung der Speicherung sowie Verarbeitung von Dateninhalten, sondern schließen auch die Gewährleistung der Konsistenz dieser ein. Semantische Integritätsbedingungen, welche aus Eigenschaften der modellierten »Miniwelt« abgeleitet werden können, realisieren die Erhaltung der Konsistenz der Dateninhalte bei Systemfehlern, ins Besondere im Einsatz unter Bedingungen von Concurrency sowie den Schutz vor unerlaubten Manipulationsvorgängen. Auch die funktionalen Abhängigkeiten aus der relationalen DB-Entwurfstherorie können zu diesen Bedingungen aufgefasst werden. Eine zentrale, automatische Überprüfung von Integritätsbedingungen ist in Relationalen Datenbanksystemen ⁷ seit ANSI-Standardisierung ⁸ SQL-89 ⁹ (gefolgt von SQL-92) implementiert, so dass veränderliche oder wachsende Konsistenzanforderungen nur einmalig gegenüber des DBMS in deklarativer Form bekannt gegeben werden, ohne manuelle

^{7 vgl. VII. Definitionenverzeichnis, Relationale Datenbank 8 vgl. VII. Definitionenverzeichnis, ANSI-Standardisierung 9} vgl. VIII. Abkürzungsverzeichnis, SQL

Veränderungen innerhalb sämtlicher konnektierter Anwendungsprogramme durchführen zu müssen. 10

1.1.1 Datenmodelle (DM)

Aus Anforderungssicht der Datenmodellierung ¹¹ stellen DM (im praktischen Sprachgebrauch oftmals als Datenbankmodelle bezeichnet, um unmissverständlichen Bezug zu Datenbanksystemen herzustellen) bezüglich vorrangig permanent gespeicherter Daten, generische Strukturen sämtlicher Datenobjekte ¹² respektive Beziehungen untereinander sowie anwendbare DB-Operatoren ¹³ und deren Wirkungsweisen dar und beschreiben diese mittels grafischer Notationen meist in Form von Diagrammen respektive textueller Beschreibungen. Es sind zielgerichtet sämtliche relevante Merkmale vollständig und widerspruchsfrei darzustellen, um eine Datenbankanwendung konzeptuell modellieren zu können. DM bestehen aus den Teilbereichen der Datendefinitionssprache (≙Datenbeschreibungssprache, engl. Kurzform »DDL« ¹⁴ ) sowie der Datenmanipulationssprache (≙Datenverarbeitungssprache, engl. Kurzform »DML« ¹⁵ ) und bilden nachfolgende Funktionen ab: ¹⁶ ⇒ DDL: Beschreibung der Struktur abzuspeichernder Datenobjekte, wobei die Strukturbeschreibung aller Datenobjekte als Datenbankschema

⇒ DML: Anfrage-& Datenmanipulationssprache (Abfragen, Einfügen, Ändern oder Löschen von Nutzdaten, engl. Query Language)

Zur Modellierung eines DM stehen nachfolgende acht Verfahren (ausgenommen in der Praxis seltener vorzufindender Misch- und Nebenformen), untergliedert in zwei Kategorien (4:4), zur Verfügung: 18

^{10 vgl. IX. Literaturverzeichnis, Kemper, A., Eickler, A. (2004), S. 151f. 11 vgl. VII. Definitionenverzeichnis, Datenmodellierung 12 vgl. VII. Definitionenverzeichnis, Datenobjekt 13 vgl. VII. Definitionenverzeichnis, DB-Operatoren 14 vgl. VIII. Abkürzungsverzeichnis, DDL 15 vgl. VIII. Abkürzungsverzeichnis, DML 16} vgl. IX. Literaturverzeichnis, Wikipedia (2006e), o.S.

^{17 vgl. VII. Definitionenverzeichnis, Metadaten 18} vgl. IX. Literaturverzeichnis, Kemper, A., Eickler, A. (2004), S. 21-23; Date, C. J. (2005), S. 135

1 Konzeptuelle Entwurfs-Datenmodelle (nachfolgend »KEDM« bezeichnet)

⇒ Entity-Relationship-Modell (ERM) findet häufigste Anwendung, seltener auch in der Praxis als »Gegenstand-Beziehungs-Modell« bezeichnet ⇒ Semantisches Datenmodell ⇒ Funktionales Datenmodell ⇒ Objektorientiertes Entwurfsmodell

Obige KEDM eignen sich aufgrund ihrer theorieelastischen Ausprägungen nur bedingt als Implementationsschemata für eine praktische Datenmodellierung, da diese gänzlich deskriptive Modelle darstellen. Aufgrund dieser strukturell unvermeidbaren Vernachlässigung praxisrelevanter Bedingungen wird die logische Ebene eines DBMS von einem der innerhalb nachfolgender Tabelle aufgeführten DM abgebildet.

2 Logische Implementations-Datenmodelle (nachfolgend »LIDM« bezeichnet)

Nachfolgende Tabelle zeigt die Differenzierung von DM für eine logische Implementierung gemäß häufigster praktischer Verwendung (absteigend) nach aktuellem Stand dieser wissenschaftlichen Ausarbeitung innerhalb vier Konzepte:

¹⁹ vgl. VII. Definitionenverzeichnis, Beziehung

Tab. 01: Differenzierung Logischer Implementations-Datenmodelle (Quelle: Anlehnung an Schicker, E. (2000), S. 57-59)

^{20 vgl. VII. Definitionenverzeichnis, Objekt 21 vgl. VII. Definitionenverzeichnis, Objektorientierte Programmierung 22 vgl. VII. Definitionenverzeichnis, Klasse 23 vgl. VII. Definitionenverzeichnis, Datenkapselung 24 vgl. VII. Definitionenverzeichnis, Vererbungsstruktur 25 vgl. VII. Definitionenverzeichnis, Hypertext-Struktur 26 vgl. VIII. Abkürzungsverzeichnis, CODASYL-Norm 27 vgl. VIII. Abkürzungsverzeichnis, IMS 28} vgl. VII. Definitionenverzeichnis, »Vater-Sohn-Bruder-Hirarchie«

1.1.2 Client-Server-Datenbankarchitektur

Bei verteilten Datenbanksystemen (nachfolgend »DBS« bezeichnet) übernehmen Sender sowie Empfänger von Datenanfragen beziehungsweise Datenantworten gleichermaßen Server- sowie Client-Funktionalitäten, so dass diese DBS- Peer-to-Peer-Netzwerken ²⁹ Architektur in Netzwerktopologien ³⁰ wird innerhalb dieser wissenschaftlichen Ausarbeitung aus Gründen der Anforderungen an die Gesamtkomplexität nicht eingegangen, jedoch ist das Verständnis dieses Fachbereichs für den weiteren Verlauf relevant.) Nachfolgende Abbildung verdeutlicht die grundlegenden, architektonischen Unterschiede von verteilten DBS gegenüber zentralisierten Lösungen in Form einer Client-Server-Datenbankarchitektur (nachfolgend »CSDA« bezeichnet):

Abb. 02: Zentrale versus verteilte Datenbanksysteme ^{(Quelle: Anlehnung an Schicker, E. (2000), S. 53)} CSDA sind historisch durch den ökonomischen Gedanken, kostenintensive Ressourcen wie beispielsweise Massenspeichersysteme sowie Prozessorleistung zentralisiert zur Verfügung zu stellen, entstanden. Von anfänglich zentralisierten Dateiservern (Fileserver-Lösungen der Firma Novell) wurde dieser Gedanke ebenso für die Haltung und Verarbeitung von Massendaten zu Datenbank-Serversystemen für die Umgebung einer CSDA entwickelt, welche maßgebend nachfolgende vier Kriterien erfüllen sollen – diese jedoch mit steigendem Anwendungsumfang in der Praxis zunehmend schwieriger realisierbar werden.

²⁹ vgl. VII. Definitionenverzeichnis, Peer-to-Peer-Netzwerk

³⁰ vgl. VII. Definitionenverzeichnis, Netzwerktopologie

⇒ Zuverlässigkeit (redundante Hardware-& Softwaresysteme zur

Dienste-Konsolidierung; RAID ³¹ + FailOver Clustering ³² ) ⇒ Performance ⇒ Integrität ⇒ Sicherheit Permission Assignment) durch so genannte Datenaufsichtssprache (engl. Data Control Language (DCL) ³³ ), Verschlüsselungsmechanismen) ⇒ Skalierbarkeit Eine CSDA besteht aus den beiden logischen Komponenten der Clients (Dienste-Nutzer) sowie einem oder mehrerer Server (Dienst(e)-Anbieter), wobei diese Rollen letztlich nur durch Ihre jeweils ausgeübten, per Software spezifizierten Funktionen definierbar sind, so dass beispielsweise ein Serversystem als Client operiert, indem dieser Datenbestände eines weiteren Servers abfragen kann, um eine Clientanfrage vollständig beantworten zu können. Eine Einteilung von Hardwaresystemen in die Begriffsdefinitionen des Frontends ³⁴ (clientseitig) sowie Backends ³⁵ (serverseitig) ist durchaus in der Praxis gebräuchlich, vernachlässigt jedoch, dass beide obige Begriffe ausschließlich im Kontext mit Software-Komponenten stehen und keinerlei Hardwarebezug aufweisen. 36

1.1.3 Verteilungsebenen eines Datenbanksystems

Es werden mittels nachfolgender Tabelle fünf Verteilungsebenen eines DBS differenziert, um dessen divergente Funktionalitäten, welche mittels eines DBMS zu einer ganzheitlichen Struktur vereint werden, aufzuzeigen:

³¹ vgl. VIII. Abkürzungsverzeichnis, RAID

^{32 vgl. VII. Definitionenverzeichnis, FailOver Clustering 33 vgl. VII. Definitionenverzeichnis, Data Control Language 34 vgl. VII. Definitionenverzeichnis, Frontend 35 vgl. VII. Definitionenverzeichnis, Backend 36} vgl. IX. Literaturverzeichnis, Brackly, G. (2006), S. 118ff.

Tab. 02: Verteilungsebenen eines Datenbanksystems (Quelle: Anlehnung an Brackly, G. (2006), S. 119)

Die am häufigsten in Unternehmungen anzutreffende Form ist, dass Präsentationssowie Steuerungsebene (P+S) explizit clientseitig übernommen werden, wobei je nach Einsatzszenario zudem die Ebene der Anwendungslogik (A) sowie seltener Bestandteile der Datenverwaltungsebene (G) zu den clientseitigen Aufgabenfeldern

zählen (Maximaltätigkeitsfeld der Clients = P+S+A+G), hingegen die gesamte Datenhaltung sowie -verwaltung (D+G) explizit serverseitig mittels des DBMS übernommen werden, welches zudem meist Bestandteile von Aufgabenfeldern der Ebene der Anwendungslogik realisiert (Maximaltätigkeitsfeld des serverseitigen

DBMS = D+G+A). Die Ebenen der Anwendungslogik (A) sowie Datenverwaltung (G) können theoretisch ebenso geteilt von Client-Applikationen sowie Serverdiensten (beispielsweise so genannte »Stored Procedures« ³⁹ ) realisiert werden. Zugleich kann die Ebene der Datenhaltung (D) über mehrere DB-Server verteilt werden, welche als so genannte »Verteilte Datenbanken« (siehe Kap. 1.1.2, S. 06) zu charakterisieren sind, so dass diese jeweils bei Anfragen als Server und/oder als Client in Bezug auf im Clusterverbund zusätzlich eingebundene Server agieren. 40

1.1.4 Three Tier-Architekturmodell für Microsoft Access-Datenzugriffsseiten

Eine zweischichtige DB-Anwendungsarchitektur (nachfolgend »2T-Architektur« bezeichnet, engl. »Two Tier Architecture«) ist eine CSDA, die softwareseitig als zweischichtiges System aufgebaut ist, so dass die Rechenkapazität signifikant auf sämtliche Clients (sog. Fat-Clients ⁴¹ ) ausgelagert wird, um die Ressourcen des / der Server(s) zu entlasten, so dass serverseitig ausschließlich die DB-Applikation

³⁷ vgl. VII. Definitionenverzeichnis, Constraint

^{38 vgl. VII. Definitionenverzeichnis, Datenbanktrigger 39 vgl. VII. Definitionenverzeichnis, Stored Procedure 40} vgl. IX. Literaturverzeichnis, ebd.

⁴¹ vgl. VII. Definitionenverzeichnis, Fat-Client

bereitgestellt wird und sämtliche Clients die gesamte Logik sowie Darstellung der Benutzerschnittstelle ausführen.

Dieser eingeschränkten Anwendungsarchitektur entgegen, stellt die Multi-Tier-Architektur (mehrschichtige Architektur, engl. »Multitier Architecture«) eine Weiterentwicklung dar, so dass die DB-Applikation in mehrere diskrete Komponenten aufgeteilt werden kann. Meist erfolgt diese Differenzierung in die so genannte Dreischichtenarchitektur (nachfolgend »3T-Architektur« bezeichnet, engl. »Three Tier Architecture«), bei welcher eine Einteilung in Datenbank, Anwendungslogik und Präsentation (Web-Oberfläche oder Client-Applikation) erfolgt, wobei jede dieser Komponenten auf separaten Servern operieren kann. Bei der 3T-Architektur agiert indessen das Thin-Client-Konzept ⁴² , so dass ein Client seine Daten möglichst vollständig von einem Server bezieht, um dessen Ressourcen für eine Vielzahl an Clientanfragen freizugeben. Dem zu folge existiert bei dieser dreischichtigen Architektur eine zusätzliche Logikschicht, welche die Datenverarbeitung vornimmt. ⁴³ Aufgrund des theoretisch beliebig weiter fortsetzbaren Aufteilungsprinzips, ins Besondere in Bezug auf Bestandteile der Logikschicht (siehe nachfolgende Tabelle), wird diese Anwendungsarchitektur ebenso als »n-schichtige Architektur« bezeichnet. Nachfolgende Tabelle stellt das Reihen-/ Schichtkonzept der 3T-Architektur sowie dessen Obliegenheiten dar:

Tab. 03: Three Tier-Architekturmodell (Quelle: Anlehnung an Wikipedia (2006a), o.S.; Mills, R. (2001), S. 303)

Mehrschichtige Systemarchitekturen wie die obige dreischichtige Architektur eignen sich ins Besondere für eine Skalierung, da die einzelnen Schichten logisch voneinander getrennt sind. So kann beispielsweise die Datenschicht auf einem zentralen Datenbank-Server operieren, die Logikschicht auf Workgroup-Servern und letztlich befindet sich die Präsentationsschicht auf der jeweiligen Workstation

⁴² vgl. VII. Definitionenverzeichnis, Thin-Client

⁴³ vgl. IX. Literaturverzeichnis, Wikipedia (2006a), o.S.

des clientseitigen Benutzers. Diese Form äußert ebenso vorteilige Eigenschaften während Entwicklungs- sowie Wartungsphasen, da einzelne Schichten separat austauschbar sind, ohne Veränderungen anderer Schichten herbeiführen zu müssen.

Die nachfolgende Abbildung 03 (S. 10) veranschaulicht die Differenz von 2T-

gegenüber 3T-Schichtarchitekturen, hingegen wird innerhalb Abbildung 04 (S. 10) diese Architektur (3T) im Hinblick eines DB-Onlineeinsatzes mittels Microsoft Access-Datenzugriffsseiten (DAP) dargestellt.

Abb. 03: Two Tier-/ Three Tier-Schichtarchitektur (Quelle: Entnahme aus Wikipedia (2006c), o.S.)

Abb. 04: Three Tier-Architektur für Microsoft DAP-Onlinezugriff (Quelle: Anlehnung an HelpdeskTools (2006), o.S.)

1.2 Begriffsdefinitionen

Im Folgenden wird nach erfolgter Einführung in allgemeine Thematiken von DBS auf Microsoft Access-Datenzugriffsseiten fokussiert und beginnend deren Bedeutung aufgezeigt.

1.2.1 Data Access Pages (DAP) als Bestandteil von Microsoft Access

DAP (dt. Datenzugriffsseiten) ermöglichen die Interaktion mittels Webbrowser ⁴⁴ mit Microsoft Access-Datenbanken (nachfolgend »MSADB« bezeichnet), ohne dass eine serverseitige Scriptsprache (beispielsweise finden Microsofts Scriptsprachen ASP ⁴⁵ / ASP.NET ⁴⁶ unter anderem für diese Zwecke Verwendung) angewandt werden muss. ⁴⁷ Diese Form des DB-Zugriffs ermöglicht die Realisierung der Nutzung eines global zugänglichen Microsoft Access-Projekts als DBS, so dass Clients via Intranet ⁴⁸ (LAN ⁴⁹ oder VPN-Verbindung 50 über Interneteinwahl) oder unter sicherheitsbezogenen Zusatzbedingungen (siehe Kap. 3.2, S. 33) auch per unmittelbarer Internetverbindung Zugriff auf das DBS gewährleistet werden kann, technisch so umgesetzt, als wären diese lokal mit den jeweiligen Quellen der MSADB verbunden.

Bei DAP handelt es sich um HTML-Seiten, welche mit Hilfe eingelagerter ActiveX-Controls (siehe Kap. 1.2.2, S. 16) in der Lage sind, eine vollständige Eingabemaske respektive Datensatznavigator sowie Tabellenansicht webbrowseroptimiert bereitzustellen, wobei diese Seiten nicht innerhalb der DB-Struktur, sondern als externe HTM(L)-Dateien gespeichert werden. Zusätzliche Verbindungsinformationen werden als XML ⁵¹ -Quelltext in die jeweilige HTM(L)-Seite integriert, so dass innerhalb der MSADB (MDB ⁵² -/ ADP ⁵³ -Dateiformat) lediglich grundsätzlich lokale Pfadangaben im Sinne von Daten- Verknüpfungsinformationen ⁵⁴ zueiner beliebigen Anzahl an DAP inklusiv abgespeichert werden. 55

⁴⁴ vgl. VII. Definitionenverzeichnis, Webbrowser

^{45 vgl. VIII. Abkürzungsverzeichnis, ASP 46 vgl. VII. Definitionenverzeichnis, ASP.NET 47 vgl. IX. Literaturverzeichnis, Doberenz, W., Kowalski, T. (2004), S. 553 48 vgl. VII. Definitionenverzeichnis, Intranet 49 vgl. VIII. Abkürzungsverzeichnis, LAN 50 vgl. VIII. Abkürzungsverzeichnis, VPN 51 vgl. VIII. Abkürzungsverzeichnis, XML 52 vgl. VIII. Abkürzungsverzeichnis, MDB 53 vgl. VIII. Abkürzungsverzeichnis, ADP 54 (mögliche Verbindungsressourcen sind; Lokales Dateisystem, UNC-Netzwerkfreigabe, FTP / WebDAV via Internet) 55} vgl. IX. Literaturverzeichnis, ebd., S. 553f.