ActiveX-Server für PL/SQL-Packages

Der erste Impuls eines Entwicklers dürfte sein, den Beispielen im Handbuch zu folgen und die Datenbanklogik direkt in den Code zu programmieren. Diese Praxis führt zu einem erheblichen Wartungsaufwand, eine einzige Änderung an der Datenbanklogik oder der Wechsel zu einem anderen Datenbanktreiber kann stundenlanges Suchen und Ändern im Code erfordern. Außerdem wird es schwierig, die Performance anders als mit einem Quellcode-Debugger zu analysieren.

Ein besserer Ansatz besteht darin, den Datenbankserver als echten Server zu betrachten, also als einen Server, der einen Satz von Geschäftslogik-Services bereitstellt, der vollständig von der Codelogik getrennt ist. Dies ermöglicht das Testen und die Pflege dieser Services unabhängig vom Code und bevor man sie mit Code verbindet. Eine Anwendung sollte niemals wissen, dass es so etwas wie eine EMP-Tabelle gibt, nur dass es eine Schnittstelle gibt, auf die man zugreifen kann, um herauszufinden, „wie viele Mitarbeiter es gibt“, oder um „das Gehalt von Mitarbeiter X zu erhöhen“.

Unter 32-Bit-Windows besteht die gängigste Methode zur Bereitstellung einer allgemeinen Schnittstelle für die meisten Programmiersprachen in ActiveX- oder COM-Servern. Dies sind DLLs oder ausführbare Dateien, welche eine Schnittstelle sowie Dienste für viele unterschiedliche Programmierumgebungen bereitstellen. Das Programmieren von ActiveX-Komponenten ist häufig eine echte Herausforderung, außerdem erfordern diese Komponenten intensive Pflege.

Visual Basic 6.0-Programmierer können sich das Leben mit dem Oracle Objects for OLE Code Wizard for Visual Basic erheblich erleichtern. Mit diesem Assistenten kann man eine ActiveX-Komponente erstellen, um den Datenbankcode für die Entwickler zu verpacken, ohne dass man dazu viel Visual Basic-Code schreiben muss.