Die nachfolgend diskutierten Fälle sollten mögliche Konsequenzen aus dem Nicht-Vorhandensein von bestimmten technologischen Merkmalen, hier der aktiven Datenbankinstanz, veranschaulichen.
Der Gegenstand der Analyse (aus dem Jahre 2004 – Anmerkung anno 2009) ist jeweils eine typische Desktop-Software, basierend auf einer Access-Datenbank mit dem dazugehörigen Interpreter fürs Basic. Auf die explizite Benennung der jeweiligen Softwareprodukte verzichten wir wohlwollend 😉 – verwenden stattdessen den Kunstnamen „WinXY“, wobei Affinitäten zu den bestehenden Produkten rein zufällig und in keiner Weise beabsichtigt sind. Unsere Fälle, auf den in zahlreichen FAQ-Artikeln unserer Website Bezug genommen wird, liegen folgendermassen:
Fall 1:
Ein kleineres Speditionsunternehmen in der Schweiz wendet seit einigen Jahren die WinXY-Software für die Bereiche des Auftrags- und Logistikwesens an. Im Frühjahr 2004 beschliesst der Geschäftsführer und Inhaber einige transObjects®-Anwendungen für elektronische Verzollungsverfahren anzuschaffen. Fortan betreibt er diese an mehreren Standorten, darunter auch mobil vom Lieferfahrzeug aus und auch am Hauptstandort neben WinXY im gleichen LAN. Zunächst versetzt ihn das Ansprechverhalten von transObjects® an externen Standorten in ein nicht schlechtes Staunen, hat er sich doch bereits vor einigen Jahren Ähnliches mit WinXY glatt abgeschminkt: Es hatte sich schlicht nichts von der Stelle bewegt!
Trotz Einschränkung der Anwendung von WinXY auf die Grenzen des lokalen Netzwerkes am Hauptstandort (noch vor der transObjects®-Zeit) verschärften sich die Probleme stetig weiter. Während es für den Benutzer direkt am Server gerade noch ging, wurde das Ansprechverhalten von WinXY an den jeweiligen Workstations immer unangenehmer, bis schlicht unzumutbar. Eine Datenbankabfrage, die einem weit zurückliegenden Vorgang galt, konnte schon mal ein paar Minuten dauern und so lange könne man einen Kunden ja nicht am Telefon hinhalten, wie der betroffene sympathische Tessiner einmal zu uns sagte… 😀
Notgedrungen (oder vielleicht müsste man sagen, WinXY-gedrungen) griff unser Kunde seinerzeit zu Windows-Terminals. Dadurch entschärfte er ein wenig die Problematik des Ansprechverhaltens an den Workstations, wenn auch zum Preis diverser anderer Probleme, etwa mit den Peripheriegeräten. Völlig entnervt orderte er schliesslich eine neue High-End-Hardware und erhoffte sich dadurch seine Sorgen loswerden zu können. Unser Verweis auf das nach wie vor souveräne Ansprechverhalten von transObjects® geriet in den Hintergrund; stattdessen ruhten alle Hoffnungen nun auf der neuen Hardware mit dem neuen Betriebssystem.
Wie die Geschichte ausging, kann sich jeder technisch bewanderte Leser leicht denken: WinXY lief auch auf einer noch so guten Hardware nicht viel besser, also musste unser Tessiner zurück zu den Windows-Terminals, wobei Inkompatibilitäten des Windows 2003 zu diversen Peripheriegeräten, die unschwer vorauszusagen waren, auch prompt eingetreten sind. Sein Gemütszustand ist mit seinem „Aaach! Es ist doch alles hoffnungslos!“ (oder so ähnlich…) am besten umschrieben.
Und was war in dieser Zeit mit den transObjects®-Applikationen los? Ja, die verrichteten ihre Dienste stets ohne Anstalten, so dass man sie in dem ganzen Wirrwarr schlicht vergessen hatte. Ob auf der alten oder neuen Hardware, von externen Standorten aus oder via GPRS-Verbindung vom Fahrzeug aus, ob über den Datenbankserver am Hauptstandort oder über das kurzzeitig dazwischen geschaltete Datacenter: auf transObjects® war immer Verlass!
Fall 2:
Ein mittelständischer Logistiker und Dienstleister wendet transObjects®-Applikationen mit durchaus hoher Intensität an und zwar an den drei grössten Passagierflughäfen in der Schweiz und vereinzelt auch im Ausland. Für die Finanzbuchhaltung schafft er sich u.a. aus historisch gewachsenen Gründen die WinXY-Software an. Den potentiellen Performanceproblemen der Desktopsoftware WinXY hofft er durch ein optimales Handling beikommen zu können: Getrennte Datenbankfiles für die jeweiligen Mandanten und eng gesteckte Abrechnungszeiträume, möglichst ein exklusiver Zugriff nur eines „single“-Clients auf die jeweiligen Datenbankfiles etc.
Diese Massnahmen ermöglichten zwar der zuständigen Abteilung des Unternehmens die klassischen FiBu-Aufgaben einigermassen zuverlässig erledigen zu können. Allerdings musste auf weitergehende Funktionen, wie etwa die betriebswirtschaftliche Auswertung, wie sie transObjects® processPRO in den Probeläufen im Nu erledigte, gänzlich verzichtet werden, denn eine Auswertung über grössere Zeiträume hinweg hätte ja geheissen, die zuvor aufgesplitterten Datenbankfiles nacheinander „abklappern“ zu müssen. So gesehen war es nicht unbedingt überraschend, dass ein Versuch dies doch noch zu tun in einem totalen Fiasko endete: Clients, die solche Auswertung starteten, gaben anschliessend leider nicht zu erkennen, ob sie sich bereits aufgehängt hatten oder noch am rechnen waren… Auf die Frage, was denn nun zu tun sei, antwortete jemand scherzhaft, „Reset-Taste betätigen“… 😉
Leider war die Konsequenz einer solch unsanften Massnahme zumeist eine Inkonsistenz von den Datenbankfiles. Solche Datenbankfehler waren weitaus ärgerlicher, als die dadurch begrenzte Anwendbarkeit von WinXY. Der Alltag in der FiBu-Abteilung sah doch so aus, dass man vor jeder grösseren Operation, etwa einem Buchungslauf, die Datenbankfiles sichern musste, um sie dann im Falles eines Fehlers in den Ausgangszustand zurück versetzen zu können. „S’ischt mühsam“ war häufig zu hören.
Damit aber noch nicht genug. Die Datenbankfehler waren leider an der Tagesordnung und nicht immer war man bereit, den halben Arbeitstag durch den File-Restore „ungeschehen“ zu machen. In anderen Fällen waren wiederum die Datenbankinkonsistenzen so schwer, dass die beschädigten Files nur durch äusserst aufwendige Reparaturen (erforderlich war das Einschicken der Files an den Softwarehersteller!) wieder instand gesetzt werden konnten. Gewiss war die Umgebung, in der WinXY betrieben wurde, nicht ganz optimal: LAN-Störungen waren des Öfteren zu verzeichnen und die Verfügbarkeit des Files-Servers war auch fernab von „100 pro“. Aber das alles war fürs transObjects® genau gleich und dort ist eine Datenbankinkonsistenz im Laufe des 10-jährigen Betriebes kein einziges Mal vorgekommen…