SQL-Datenbanken, VBA Office Automation & COM Addins, VB SchnittstellenprogrammierungSQL-Datenbanken...

 

Home
Kernkompetenzen...
Vorgehensweise...
SQL-Datenbanken...
Schnittstellen...
Suchen und Filtern
Office Automation
Projekthistorie...
Kunden
Referenzen
AddIns & Tools...
KnowHow...
Leistungen...
Kontakt...
Feedback...

Nach oben


Datenbanken allgemein

Neben dem Verständnis, welchem Zweck eine Datenbank aus Sicht der AnwenderInnen eigentlich dienen soll, sind zwei weitere Punkte beim Datenbankdesign von großer Bedeutung.

Punkt 1 ist der aktuelle bzw. gewünschte Datenfluß, also die exakte Kenntnis, woher und in welchem Format die Daten kommen und was mit ihnen passieren soll. Dieser Punkt setzt eine intensive Beschäftigung mit der eigentlichen Aufgabe und den real vorliegenden Daten voraus.

Punkt 2 ist ein sehr gutes Verständnis der in Frage kommenden Datenbanktechnologien. Hierbei stehen im Bereich der relationalen Datenbanken neben den Datenbank-Servern wie bspw. Oracle oder dem SQL-Server auch sogenannte Desktop-Datenbanken zur Auswahl. Die Erfahrung zeigt, daß viele Anwendungen durchaus erfolgreich mit bspw. MS Access realisiert werden können, wenn mit Access professionell entwickelt wird. Liegen gute Gründe vor, einen Datenbank-Server einzusetzen, wird häufig eine SQL-Server Datenbank in Kombination mit einem Access-Frontend eingesetzt. Es besteht aber keine prinzipielle Beschränkung auf diese Kombination; als Alternativen kommen alle SQL-Datenbanken von der kostengünstigen MSDE bzw. dem Nachfolger SQLX, der lizenzkostenfreien Variante des MS SQL-Servers 2000 bzw. 2005 oder Oracle Datenbanken sowie das klassische Visual Basic bzw. der Nachfolger VB .Net in Betracht. 

Desktop-Datenbanken

Beim Einsatz einer Desktop- bzw. Jet-Datenbank hat sich der folgende Standard bewährt und bildet daher häufig die technische Basis eines neuen Projekts:

bullet

Entwicklung von Oberfläche und Datenhaltung mit MS Access

bullet

Problemlose Wartbarkeit durch Trennung von Code und Datenhaltung
(Verwendung von Front- und Backend)

bullet

Optimierung der Formularoberflächen durch Verwendung von Windows API

bullet

Ausschließliche Verwendung von VBA-Code, keine Makros

bullet

Namenskonvention gemäß der ungarischen Notation

bullet

Verwendung von bewährten Klassen für alle Basisfunktionen

bullet

Fehlerbehandlung in allen Prozeduren

bullet

Automatisches Fehlerprotokoll mit der Möglichkeit, dies bei Bedarf per Mail zu verschicken

Die folgenden Einzelfunktionen sind langjährig erprobt und bei Bedarf schnell realisierbar:

bullet

Optimierte Such- und FiIterfunktionen

bullet

Flexible Steuerung für Formularfelder (bspw. „editierbar“, „gesperrt“, „farbig“ oder „Pflichtfeld“)

bullet

Flexible Steuerung für Listenformulare (bspw. benutzerdefinierte Feldauswahl, Anordnung und freie Spaltenbezeichnungen trotz MDE-Format)

bullet

Flexible Filtermaske für Listenformulare

bullet

Dynamische Erstellung bzw. Änderung aller DAO/ADO Objekte zur Laufzeit

bullet

Digitale Unterschriften (Digital Signature) für Berichte

bullet

Import von beliebigen, benutzerdefinierten Datenformaten inkl. Unicode

bullet

Export beliebiger, benutzerdefinierter Datenformate inkl. Unicode

bullet

Datenausgabe nach Word, Excel, PowerPoint

bullet

PDF-Druck  mit automatischer Vergabe des Dateinamens

bullet

Mail-Versand

bullet

Fax-Versand

bullet

Integration des Windows Kalenders inkl. Unterstützung von Unicode Fonds

bullet

Konfigurierbare Farbeinstellungen

bullet

Anzeige animierter Logos

bullet

Mehrsprachigkeit für Masken und Berichte

bullet

Formularanpassung für verschiedene Bildschirm-Auflösungen, auch bei verschiedenen Breiten/Höhenverhältnissen

bullet

Verwendung digitaler VBA-Zertifikate (Digital Signed Projects)

bullet

Anzeige der momentan angemeldeten Benutzer

bullet

Auslieferung der Anwendung per Setup, optional mit Access Runtime Version

Update- oder Release-bedingte Änderungen bzw. Erweiterungen der Datenstruktur sind langjährig erprobt und bei Bedarf schnell realisierbar:

bullet

Skriptgesteuerte Tabellen

 

Serverbasierte Datenbanken

Häufige Gründe, für die Datenhaltung einen Datenbankserver an Stelle einer Jet-DB einzusetzen, sind:

bullet

Datenvolumen

bullet

Anzahl der gleichzeitigen Benutzer

bullet

Art der Anwendung

bullet

Sicherheitsanforderungen

bullet

Performance

bullet

Replikation

Die Vorgehensweise bei der Entwicklung einer Server-Datenbank ist dabei im Regelfall:

bullet

Analyse & Entwicklung eines relationalen Datenmodells

bullet

Realisierung des Datenmodells

bullet

Entwicklung der Businesslogik in Form von Views, Triggern und Stored Procedures

bullet

Nutzung rollenbasierter Sicherheitskonzepte

bullet

Skripterstellung für alle Objekte

bullet

Implementierung in Kundenumgebung/Tests

bullet

Erstellung und Realisierung eines Backup-Konzepts

 

Für die dynamische Einbindung von Tabellen und Views sowie die Verwendung von PassThrough-Queries stehen bewährte Module zur Verfügung, die einen problemlosen Versionswechsel und die Verwendung der verschiedensten Sicherheitskonzepte (Server basiert, Client basiert, Windows-Security) ermöglichen.