vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
Brandneu! sevEingabe v3.0 - Das Eingabecontrol der Superlative!  
 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

Visual-Basic Einsteiger
Re: Datenbanken sperren 
Autor: unbekannt
Datum: 01.02.02 16:08

Hi Madmax,

der Fehler tritt nur bei zwei Zuständen auf: Bei Addnew also wenn ein Datensatz hinzugefügt wird oder bei Edit - wenn Datensätze von einem Anwender geändert werden.
Microsoft AccessDB's haben hier aber eine kleine Besonderheit: Selbst bei optimistischer Einstellung eines Schreibzugriffs über das Recordset-Objekt wird eine Tabelle zumindest partiär gesperrt - obwohl der ander User gar nicht an dem gleichen Datensatz Änderungen vornimmt bzw. nur einen Datensatz hinzufügt und der andere User einen Datensatz ändert. Access sperrt immer eine komplette Page, die bei der Einstellung dbOptimistic aber immer noch die Größe von 2kB hat. D.h. in einem Bereich von 2 kB um den betreffenden Datensatz herum kann immer nur einer Änderungen vornehmen.
Es entsteht ein auffangbarer Laufzeitfehler, wenn dieser Fall eingetreten ist. Die Kunst liegt nun darin, diese Laufzeitfehler so zu steuern, dass der zuletzt eintretende User für eine kurze Zeit (WinApi Sleep verwenden) auf eine Wartebank gesetzt wird und der Vorgang dann wiederholt wird.

Beispiel:

On Error Goto Zugriffehler

Db.Beginntrans
With Rs
.Edit
....
....
.UpDate
End With
Db.Committrans

Exit Sub

'Errorhandle
Zugriffehler:
Select Case Err.Number
Case 3021 'ist nur Beispiel .....
'Tabelle ist von Benutzer gesperrt
DB.Idle 'erzwingt die Bereinigung des DB Cache
DoEvents
Sleep 100
Resume
Case 3051 'ist nur Beispiel .....
'Anderer Fehler ....
DB.Idle
DoEvents
Sleep 100
Resume
End Select
End SubLeider tritt hierbei nicht nur ein bestimmter Fehler auf, sondern kann eine ganze Palette davon erzeugt werden, man muß jeden einzelnen Fehler genau schecken und die Wartezeiten definieren. Was man noch Einbauen muß ist ein Timoverflow. D.h., wenn es der Client soundsolange propiert hat in den Datensatz zu schreiben, ist etwas Anderes faul und die Prozedur bzw. Transaktion muß abgebrochen werden.


cu
Lordchen
alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
Datenbanken sperren57Madmax01.02.02 15:40
Re: Datenbanken sperren269unbekannt01.02.02 16:08
Re: Datenbanken sperren36Madmax01.02.02 16:28
Re: Datenbanken sperren214unbekannt01.02.02 16:35
Re: Datenbanken sperren37Madmax01.02.02 16:43

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