vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
Zippen wie die Profis!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2025
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

VB & Datenbanken
Re: DAO od. SQL-Methoden - Vor-/Nachteile ? 
Autor: MarcG
Datum: 29.04.08 22:12

wb-soft schrieb:
Zitat:

Mehrbenutzereinsatz
mit der Jet-Engine ist kein Problem. Wenn doch, liegts am
Programmierer.

Eben. Und bei einem Mehrbenutzersystem sollte es nicht am Programmierer liegen.

Dass die Jet-Engine nicht für den Mehrbenutzereinsatz nicht geeignet ist, kann jeder selbst ausprobieren, in dem er sich ein kleines Testprogramm schreibt, zwei oder drei Instanzen davon startet und diese gleichzeitig in eine Jet-DB schreiben lässt. Ein zweites Testprogramm liest die Daten. Nach ca. einer Viertelstunde werden die ersten fehlerhaften Datensätze auftreten. Die Anzahl der Verbindungen spielt da keine Rolle - es müssen nur mindestens zwei sein. Es kommt auf die Gleichzeitigkeit an. Die Wahrscheinlichkeit, dass gleichzeitig Schreibzugriffe auf die gleiche Seite erfolgen, ist bei mehr Verbindungen natürlich höher. Aber prinzipiell reichen zwei Benutzer, um eine Jet-Datenbank zu schrotten.

Die Jet-Engine ist ein Desktopsystem und damit ein Einzelnutzersystem. Dass man mehrere Verbindungen öffnen kann, heißt noch lange nicht Mehrbenutzereinsatz. Diese Verbindungen können auch von ein und dem selben Nutzer auf der selben Maschine hergestellt werden. Wenn er diese Verbindungen nicht gleichzeitig zum schreiben nutzt, kann dabei auch nichts kaputt gehen.

Aber die Frage war ja, wie man im Mehrbenutzerbetrieb vermeidet, dass was kaputt geht und die prinzipiell richtige Antwort war, dass das am Programmierer liegt. Was heißt das konkret?

Erstens dass nur Programme dieses Programmierers auf die Datenbank zugreifen dürfen. Sonst kann der Programmierer für nichts garantieren.

Ansonsten gibt es prinzipiell zwei Vorgehensweisen. Die eine ist, dass man jeden Zugriff in eine Transaktion packt. Das geht über die BeginTrans- und CommitTrans-Methoden des Workspace bzw. DBEngine-Objektes der DAO. Der Schwachpunkt hier ist, dass wenn ein Nutzer viele Zugriffe schnell hintereinander hat, blockiert er die anderen Benutzer. D.h. ein Nutzer hat normale Verarbeitungssgeschwindigkeit, bei den anderen passiert alles nur im Schneckentempo. Wenn also öfter größere Datenmengen importiert werden (z.B. aus einer CSV-Datei o.ä.) und das vielleicht noch von mehreren zu gleichen Zeit, dann wird das ein Problem. Ansonsten nicht.

Die zweite Möglichkeit ist, dass man die Datenbank immer exklusiv öffnet, seine Schreib-/Leseoperationen durchführt (und zwar in kleinen Mengen) und anschließend die Datenbank wieder schließt. Auf diese Weise können mehrere Nutzer "gleichzeitig" große Mengen schreiben. Es muss beim Öffnen der Datenbank eben der Laufzeitfehler, dass die DB exklusiv durch einen anderen Nutzer geöffnet ist, abgefangen werden. Man versucht so lange die DB zu öffnen, bis es geht oder ein Timeout erreicht ist. Die Performance ist zwar dann nicht berauschend, aber bei allen ungefähr gleich und auch bei mehr als zehn Nutzern noch akzeptabel.

Mit der Frage DAO oder ADO hat das ganze nichts zu tun. Die DAO sind schnell, bugfrei und holen aus der Jet-Engine alles raus. Es gibt keinen Grund, eine bestehende DAO-Anwendung auf ADO umzuschreiben. Man gewinnt dadurch nichts - im Gegenteil. Man verliert Performance und Möglichkeiten.

Bei einer neuen Anwendung muss man sich überlegen, ob sie nur mit der Jet-Engine oder auch mit anderen Datenbanksystemen arbeiten soll. Soll sie nur mit der Jet-Engine arbeiten, empfiehlt es sich auch dann, die DAO zu verwenden. Dass die DAO nicht mehr weiterentwickelt werden ist kein Argument. Zum einen gibt es da kaum was zu verbessern, zum anderen werden auch die ADO nicht mehr weiterentwickelt.
alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
DAO od. SQL-Methoden - Vor-/Nachteile ?1.502Wolfgang Schwarz28.04.08 12:30
Re: DAO od. SQL-Methoden - Vor-/Nachteile ?1.121MarcG29.04.08 16:47
Re: DAO od. SQL-Methoden - Vor-/Nachteile ?1.152ModeratorDieter29.04.08 17:36
Re: DAO od. SQL-Methoden - Vor-/Nachteile ?988Wolfgang Schwarz29.04.08 18:15
Re: DAO od. SQL-Methoden - Vor-/Nachteile ?1.047wb-soft29.04.08 17:50
Re: DAO od. SQL-Methoden - Vor-/Nachteile ?1.130MarcG29.04.08 22:12
Re: DAO od. SQL-Methoden - Vor-/Nachteile ?1.167Wolfgang Schwarz30.04.08 07:55
Re: DAO od. SQL-Methoden - Vor-/Nachteile ?1.011MarcG30.04.08 11:48

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2025 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel