Betrifft CW Nr. 16 vom 19. April 1995, Seite 16: "IBM und Microsoft liessen BR mit Datenbank-Projekt im Stich" Hier beklagt ein Verantwortlicher, wie er mit seinem Projekt Schiffbruch erlitten hat. Nach wenigen Zeilen wird mir klar: Hier ist einer der Werbung ganz fuerchterlich auf den Leim gegangen.
Dass Access zur Verwaltung der angegebenen Datenvolumina allein nicht in der Lage ist, leuchtet ein, einverstanden. Daher ist auch die Idee nicht schlecht, diese Daten auf dem Mainframe verwalten zu lassen. Wenn sich allerdings jemand euphorisch ueber "eine der schoensten Programmieroberflaechen" begeistert und damit Access meint, dann hat er sicherlich nicht viel in der Richtung kennengelernt. Wenn er nun hergeht und die Zugriffslogik von Access fuer sich arbeiten lassen will, aber mit eingebundenen Tabellen aus DB2, dann macht er Access zum puren Front-end, und zwar mit fatalen Folgen. Denn erstens folgt Access nicht dem Client-Server-Modell. Das heisst, jeder Anwender muss seinen PC fuer sich arbeiten lassen, wenn die Datenquelle von sich aus nicht genuegend Funktionalitaet bietet. Wenn nun der Anwender grundsatztreu auf die Programmierung seiner Datenquellen verzichtet, dann schlaegt eben das Front-end zu. Und das muss sich die Daten nun einmal auf den PC holen, mit den bemerkten Folgen.
Die SQL-Schnittstelle von Access ist einigermassen brauchbar dokumentiert. Bei gruendlicher Lektuere der Dokumentation sollte eigentlich auffallen, dass Access-SQL nicht unbedingt dasselbe ist wie DB2-SQL. Wer mehrere SQL-Datenbanksysteme kennt, weiss sicherlich, dass - heute zumindest - an den SQL-Implementierungen das kompatibelste die Datentypen sind. Bei Access ist - ausnahmsweise sehr explizit - dokumentiert, wo hier die Abweichungen zu ANSI-SQL liegen. Das Nichtvorhandensein des Char- Datentyps bei Access war also im voraus feststellbar. Die Genauigkeit des Date-Datentyps laesst sich auch ermitteln, ohne ein grosses Projekt aufzusetzen. Die alte Erfahrung, dass man im DV- Umfeld nichts als selbstverstaendlich betrachten kann, wurde meines Erachtens ausser acht gelassen. Views mit Update-Moeglichkeit sind in der Regel nur sehr eingeschraenkt verfuegbar - klar, dass Views e la Access nicht ueber eine Standard-Schnittstelle realisierbar sind. Das SQL, das Access bei Joins erzeugt, entspricht dem ODBC- Standard. Der ist zwar etwas gewoehnungsbeduerftig und anders als ANSI-SQL, bietet dafuer aber klare Optimierungsmoeglichkeiten. Dass solche Joins erst auf Access-Seite gebildet werden, muesste eigentlich einleuchten. Mit der Jet-Engine habe ich in manchen Faellen eine ganz erstaunliche Performanz vorgefunden, und zwar bei Joins ueber so viele Tabellen, wie man sie auf einem normalen Server-System tunlichst nicht bilden sollte.
Es gibt viele Gruende, aus denen heraus ich nie auf die Idee kaeme, Access fuer ein wichtiges Projekt in Mehrbenutzer-Umgebungen einzusetzen. Die in sich bruchhafte Entwicklungsumgebung waere nur einer davon. Nichtsdestoweniger habe ich bereits mit Access entwickelt. Ich war ganz schnell weg von der grafischen Entwicklung und statt dessen bei der prozeduralen Programmierung mit Access-Basic. Grund: Behandle ich die angebotenen Konstrukte eines Werkzeuges wie eine Black box, dann verwende ich einerseits oft sehr viel ueberfluessige Funktionalitaet - auf Kosten der Performanz - und muss andererseits mit jeder Menge Ueberraschungen rechnen - auf Kosten der Qualitaet -, weil die mir unbekannte Arbeitsweise der Komponenten Nebeneffekte zeitigt. Und die wirklich gravierenden darunter kommen natuerlich erst dann heraus, wenn es kritisch wird und mein n-ter Zeitplan beerdigt werden kann. Ich selbst traue Access nun ueberhaupt nicht ueber den Weg.
Dr. Goetz Heller, Leonberg