°Junoland.de HOME     www.Junoland.de     Valid HTML 4.01 Transitional     (c) Copyright 2008 °Andreas Klotz, Cologne, Germany [upd.Oct.2008]     AKL@Junoland.de

MS Access kritisch: ADP vs. MDB vs. DotNet

Methodendiskussion - Meinung - Code-Schnipsel

Erste Fragmente eines 100-Seiten langen NotizZettels,
den ich sukzessive bis Ende 2008 an dieser Stelle einbringen möchte
in Form von Demos und kritischen Hintergrundsartikeln


Der Unterschied zwischen Access-MDB und Access-ADP

(eine auf meine persönliche Erfahrung gegründete Aufstellung)


ADP: MDB:


Alternativen zu Access

Was mir für den Einsatz von Access bedenkenswert erscheint:

Ich schaue mir gerade (Ende April 2006) C#.NET und Ado.Net 2.0 an und stelle fest, dass dort alles performant abläuft und ohne die Zwänge und Beschränkungen, die in Access gegeben sind. Ob man allerdings tatsächl. Umsteigen sollte, werde ich sehr gründlich weiter prüfen (min. 80 h lang für erste Versuche).

Die wenigen Leute, die beides wirklich gut können (Access und VB.Net oder C#), sind leider unterscheidlicher Meinung: Viele sehen für den Einsatz von Access einen Programmier-Geschwindigkeitsvorteil von Faktor 2 bis 3 gegenüber DotNet-Technik; ich selber kann das erst einmal nicht erkennen. Kann es nicht sein, dass viele einfach nur VB auf dem Stand von 1999 meinen und weniger VB.Net 2.0 oder gar C# ? ADO 2.0 ist wiederum ein gewaltiger Fortschritt gegenüber ADO.Net 1.0.

Kann es nicht außerdem so sein, dass fast alle großen Programmierer sich von solchen sogenannten Spielzeugen wie Access und VB fernhalten ? Dass meistens nur die Mittelklasse in diesem seichten Wasser schwimmt ? - Das zumindest befürchte ich. Gute Leute sind schließlich meistens in der Ecke von C++ zu finden, einige auch in der Java-Ecke und einige wenige auch bei den Mainframes und bei SAP.

Ich muss also selber beide Techniken vergleichen, indem ich nach und nach einige Dinge in C#/Ado.Net2.0 aufbaue und vergleiche. Die Zeit, die ich dafür brauchen werde (mind. 80 h) könnte ich mir nur ersparen, indem ich jemanden finde, der mir genaueste Auskunft über beide Techniken erteilen könnte.



... und ich habe inzwischen gründlich verglichen!
(Okt.2008, Details dazu im Laufe der nächsten Wochen)




Erste Sichtung der möglichen Mittel in Access

Es gibt:

A° würde bedeuten, dass man auf diese Daten nur von diesem einen PC aus zugreifen kann. Datenbank privat macht irgendwie wenig Sinn, wenn es um Betriebsdaten geht, die von vielen Mitarbeitern gelesen werden sollen.

B° hat den Nachteil, dass immer die ganze Datenfracht beim Öffnen der Datenbank-Tabellen auf den PC gepumpt werden muss, wenn man Teilgebiete lesen oder bearbeiten will; dabei können bei unsicherem Netzwerk Files im Laufe der Zeit kaputt gehen - so sagt es wenigstens die breite Meinung der Experten und so sagt es meine Erfahrung mit Lösungen dieser Art in unserem Hause.

C° Habe ich nicht getestet, haber aber ein solches Projekt von anderen Leuten kennengelernt. Ist öfters bei Netzwerkstaus kriechend langsam. Hat den Vorteil der Trennung der Oberfläche von Daten.

D° funktioniert gut, sicher und performant, zumindest bei Verknüpfung zu z.B einem DB2-Server Andere Server (AS/400) sind leider nicht performant genug beim Schreiben von Daten - zumindest bei bestem Bemühen via ADO mit den verschiedensten Einstellungen und Datenprovidern.

Achtung!!! Versuche mit einem lokalen MSDE-Server haben ergeben, dass es keine nennenswerten Performance-Nachteile bei MDB-Verknüpfung zu MSDE gegenüber ADP-Projekt gibt !!! Auch Views sind direkt auf Datenbank ablegbar, auch wenn sie nicht in der DB-Projekt-Ansicht angezeigt werden; sie lassen sich per einfachem SQL-Befehl via ADO erzeugen (CREATE VIEW...)

E° MDB hat Abfragen - ADP hat statt dessen Views (beide mit grafischer Diagramm-Oberfläche) Formulare gibt es in beiden (in MDB und in ADP). Stored Procedures gibt es nur in ADP. ADP hat keine eigene Datenhaltung mehr.

ADP funktioniert gut, sicher, aber bisher nur performanter (ca. doppelt) , wenn es um viele kurze Zugriffe hintereinander geht; bei einem einzigen Zugriff auf eine große Datenmenge ist die MDB-Methode sogar ca. 10-20 % schneller im Lesen. Dies zeigten zumindest unsere Versuche auf lokaler und Netzwerk-Ebene (ADP ca. 1000 Recs / sec schreiben und 30.000 Recs / sec lesen, MDB verknüpft zu MSDE ca. 500 Rec /sec schreiben, aber 40.000 Recs / sec lesen). ADP bedeutet Festlegung auf einen MS-Server (zumindest für verbundene Formulare?), während MDB auch auf andere verknüpfbar ist.

ADP hat außerdem Stored Procedures, MDB hat diese nicht, oder? mal sehen.....
Aber selbst wenn Stored procedures fehlen, bedeutet dies in der momentanen Phase unserer Entwicklung keinen Verlust. SP sind recht mühsam programmierbar und beschränken den Entwickler beträchtlich: Tabellenname als Übergabeprameter für eine allgemein gehaltene Funktion nicht möglich; jede SP scheint fest mit Tabelle oder Tabellen verbunden zu sein! Die Flexibilität von SP kann durch Errechnen von SQL-Statements zur Laufzeit weit übertroffen werden! Das einzige, was evtl. für SP spricht, ist die eventuell bessere Performance! Es kann aber auch das Gegenteil der Fall sein: Verteilte Rollen auf Client-PC's bei VBA-Programmierung statt SP könnten den DB-Server so weit entlasten, dass das gesamte System schneller läuft! Wenn wir also auf SP verzichten sollten, dann können wir aber immer noch einen Teil der SP-Funktionalität durch geschickte Anordnung von Views ausgleichen.
(Apropos: Können Views performant bei Bedarf dynamisch errechnet und erzeugt und wieder gelöscht werden?) [siehe auch "Unterschied ADP / MDB" einige Absätze tiefer]

F° hat folgende Einschränkungen, die dazu führen, dass diese Technik - wenn überhaupt - höchstens für reinen Intranet-Betrieb in Betracht gezogen werden könnte:
# Browser muss der MS-IE sein (nicht etwa Netscape / Mozilla / Firefox oder Opera)
# Webserver muss der MS-IIS sein
# jeder User muss über eine Access-Lizenz verfügen

Was sagt MS zu den Grenzen von MDB / JET ohne DB-Server

- Zitat aus http://support.microsoft.com/?KBID=300216 ...
"Zusätzliche Hinweise zur Datenbankpflege in Netzwerkumgebungen

Microsoft Jet ist ein Datenbanksystem mit gemeinsamem Dateizugriff. Bei einer Datenbank mit gemeinsamem Dateizugriff erfolgt die Verarbeitung der Datei auf dem Client. Wenn eine Datenbank mit gemeinsamem Dateizugriff, wie beispielsweise Microsoft Jet, in einer Mehrbenutzerumgebung verwendet wird, führen mehrere Clientprozesse Lese-, Schreib- und Sperrvorgänge für die gleiche freigegebene Datei in einem Netzwerk aus. Falls ein Prozess aus einem bestimmten Grund nicht abgeschlossen werden kann, besteht die Möglichkeit, dass die Datei in einem unvollständigen oder beschädigten Zustand verbleibt. Dies ist möglicherweise der Fall, wenn ein Client unerwartet beendet oder eine Netzwerkverbindung zu einem Server unterbrochen wird.

Microsoft Jet eignet sich nicht für die Verwendung mit hochbeanspruchten, parallelen Serveranwendungen, wie beispielsweise Web-, E-Commerce-, Transaktions- und Messaging-Servern, die 24 Stunden täglich und 7 Tage die Woche verfügbar sein müssen. "

....

"Bei Verwendung von Microsoft Jet in hochbeanspruchten Anwendungen, wie Microsoft Internet Information Server (IIS), sind bei einigen Kunden Probleme wie Datenbankbeschädigungen, Stabilitätsprobleme, wie beispielsweise der Absturz von IIS, und ein plötzliches dauerhaftes Versagen des Treibers für die Verbindungsherstellung mit einer gültigen Datenbank aufgetreten, die einen Neustart des IIS-Dienstes erfordern."

.....




Unterschied ADP / MDB

was ein alter MDB-Fahrensmann schmerzlich vermisst an ADP:




Warum überhaupt Access?

Wenn man in Access bei Zugriffen auf die eigentlichen Daten letzten Endes per ADO agieren muss, sofern man nicht einfach ganze Datenbank-Tabellen ohne weiteren Zusatz editieren lassen will, warum nimmt man dann nicht einfach das ADO von Excel, so wie in vorhergehenden Projekten in unserem Haus vorgegangen worden ist? Warum überhaupt Access?

Ich weiß es nicht genau, aber ich glaube, dass man einen guten Teil des Grundgerüsts auf Access aufbauen kann, wohingegen diese Vorgänge in Excel auf eigene Art entwickelt werden müssen.

In Excel hat man nämlich z.B. das Problem, dass man eigentlich zu jedem einzelnen Zugriff User + Password durchreichen muss. Damit der User dies nicht ständig eingeben muss, haben wir einen Workaround geschaffen, der das Passwort eines Netzusers in verschlüsselter Form in ein temporäres File schreiben lässt.

----Man kann dies allerdings dadurch lösen, dass man den Netzwerk-User-Account verwendet, so dass keine eigene Passwort-Verwaltung nötig ist.-----

Bei der aktuellen Aufgabenstellung gehe ich davon aus, dass es innerhalb einer 8-h-Arbeitsschicht viele kurze Einträge gibt, die über mehrere Stunden verteilt vorgenommen werden und ebensolche Lese-Zugriffe auf die letzten gerade notierten Ergebnisse geben wird. Es kommt wahrscheinlich weniger auf das tägliche Bearbeiten ganzer Datenserien durch einen einzelnen User an, wie wir es per Excel betreiben, sondern mehr auf die fortlaufende Aktualiserung mit den entsprechenden möglichen Zugriffskonflikten, die wie ich hoffe in Access mit den bereitgestellten Mitteln komfortabel gehandhabt werden können.

Der wichtigste Grund pro Access ist aber in meinen Augen die größere Wahrscheinlichkeit, Arbeitskräfte auf dem freien Markt zu finden, die diese Art von Vorgängen auf ähnliche Art und Weise mit dem bekannten Access-Grundgerüst regeln können. Würden wir Excel-VBA-Module schreiben, die eine ähnliche Funktionalität bieten, würden wir eine hohe Anforderung auf Einstieg in diese Art von Eigenbau-Code voraussetzen! Für Excel-VBA-Programmierung der zur Zeit bestehenden Tagesberichte in unserer Abteilung benötigten wir im Kern-Modul 4000 kompakt geschriebene Lines of Code. Dies ist im Vergleich zu anderen Projekten zwar eine eher geringe Anzahl an Zeilen, aber aufgrund der Komplexität der Aufgabenstellung und in Ermangelung eines objektorientierten Ansatz auf VBA-Basis wäre es für einen Außenstehenden schwer, sich schnell darin einzuarbeiten.

Warum nicht C#.Net 2.0 / ADO 2.0 als FrontEnd mit SQLServer als BackEnd einsetzen ?

Ist doch genau so performant wie Access, bietet auch EndlosFormulare in Form von DataGridView und ist vor allem kein Stützkorsett für Weicheier, das einem starken Programmier-Geist zur Zwangsjacke wird!

Welche Access-Hilfestellungen würde ich bei einem Umstieg auf DotNet/Ado.Net2.0 vermissen?

Heterogene Zugriffsstruktur

(unsystematisch, weil anscheinend historisch gewachsen)

Es gibt leider sehr viele übergeordnete Knoten, an denen wichtige Objekte und Funktionen geknüpft sein können:


Ein paar Schnipsel vorab

Combinationslistenfeld
Value wird manchmal nur angezeigt, wenn man den Focus auf die Form setzt: Form_iNav.SetFocus ' to force screen-refresh of this form!

ListBox mit Wertereihe befüllen Erst wenn Form_Open abläuft, nicht vorher übergeben!

Listbox Auswahlposition ermitteln
Li = Me.tempInt.ListIndex

Unligth Memory-Selections of ListBox
me.ListBox1.Value = Null ' to unlight memorized listindex

Listbox / Kombinationsfeld
Text des Auswahlpunkts ermitteln : Li = Me.tempInt.Text

Kurzform zum Enable / Disable eines Buttons etc.
Private Sub Form_Current() '"Beim Anzeigen" cmdTest.Enabled = Me.NewRecord ' enable/disable if cursor is on the new record row ''MsgBox Me.MyField End Sub

Bookmark richtig verstanden einsetzen (bei Suche in RecordsetClone)
Ein Bookmark ist nichts weiter als eine Datensatzposition!
Man kann damit z.B. den aktuellen Satzzeiger auf dieselbe Position setzen, die in einer RecorsetClone-Suche gefunden worden ist:

  Sub TestFind()
  Dim RSB As Recordset
  Set RSB = Me.RecordsetClone ' in Subforms say : Me.MySub.Form.RecordsetClone
  RSB.Find "Appname = 'C1' "
  If Not RSB.EOF Then Me.Bookmark = RSB.Bookmark  'Move to the record on the subform
  End Sub

Welche SQL-Server-Version ist das ?
- SQLstr = "select @@version"

.... (noch ca. 200 weitere Items einzubringen und thematisch zu ordnen und mit Beispielen zu versehen)