Announcement

**Andreas Kosch** · 11.11.2002, 08:13

Hallo,

>..cursorlocation auf clclient ..

in diesem Fall puffert der OLE DB Provider Microsoft JET Engine die Datenmenge in einem eigenen Speicherbereich, so das alle Schreibzugriffe zuerst nur auf die lokale Kopie erfolgen.

Aber auch dann, wenn bei clUseServer f�r die TADODataSet-Instanz das pessimistische Sperrverfahren angefordert wird, verh�lt sich die Anwendung nicht so wie erwartet:
<pre>
ADOConnection1.Connected := True;
ADODataSet1.LockType := ltPessimistic;
ADODataSet1.CursorType := ctKeyset;
ADODataSet1.Active := True;
</pre>
Wenn zwei Programminstanzen auf den gleichen Datensatz zugreifen, k�nnen beide Programminstanzen in den Edit-Modus schalten, die Daten editieren und Posten. Der "Letzte" gewinnt dabei, so dass bei Instanzen nach dem Aktualisieren der Daten immer den Wert des letzten Posts sehen.

Wird nur mit den nativen ADO-Objekten gearbeitet, tritt dieser Effekt nicht auf. Das Problem liegt also bei ADO Express - genauer gesagt liegt die Ursache im internen VCL-Cache. Denn erst beim Aufruf der Methode Post bekommen die nativen ADO-Objekte mit, dass der Anwender ein Feld des aktuellen Datensatzes ge�ndert hat. Damit sich ADO Express genauso wie die nativen ADO-Objekte verh�lt, ist ein kleiner "Kunstgriff" notwendig, wie der n�chste Versuch zeigt: Immer dann, wenn der Dummy-Edit-Modus aktiviert ist, sorgt das Programm daf�r, dass in der Ereignisbehandlungsmethode f�r das BeforeEdit-Ereignis der TADODataSet-Instanz ein Dummy-Update auf die Hilfsspalte der Tabelle (Beispiel: EditUser) gemacht wird, indem das Programm an TADODataSet vorbei direkt auf die darunterliegende Recordset-Objektinstanz zur�ckgreift:
<pre>
Recordset.Fields.Item['EditUser'].Value := sUserName;
</pre>
Damit keine wichtige Information �berschrieben wird, verwendet die Tabelle die zus�tzliche Spalte EditUser, die st�ndig mit dem jeweiligen Benutzernamen �berschrieben wird.
<pre>
{
Hilfsfunktion stempelt unmittelbar vor jedem Editiervorgang (am besten
aus der Ereignisbehandlungsmethode BeforEdit heraus) den aktuellen
Benutzernamen auf ein Hilfsfeld der Tabelle. War das erfolgreich,
liefert die Funktion TRUE zur�ck.
}

function LockEditUser(DataSet: TDataSet): Boolean;
begin
Result := False;
with DataSet as TCustomADODataSet do
if CanModify and
(CursorLocation = clUseServer) and
(LockType = ltPessimistic) then
begin
UpdateCursorPos;
Recordset.Fields.Item['EditUser'].Value := sUserName;
Result := True;
end;
end;

procedure TForm1.ADODataSet1BeforeEdit(DataSet: TDataSet);
begin
if RadioGroupMode.ItemIndex = 2 then
if not LockEditUser(ADODataSet1) then
begin
MessageBeep(0);
Abort;
end
end;

procedure TForm1.ADODataSet1BeforePost(DataSet: TDataSet);
begin
ADODataSet1EditUser.Clear;
end;
</pre>
Wird anstelle von TADODataSet die FreeWare-Komponente TBetterADODataSet (siehe http://web.orbitel.bg/vassil/) eingesetzt, so vereinfacht sich die Implementierung. TBetterADODataSet macht die notwendigen Schritte immer dann automatisch, wenn die folgenden Kriterien eingehalten werden: 
1. CursorLocation ist clUseServer 
2. LockType ist ltPessimistic 
3. OLE DB-Provider ist die Jet-Engine (ACCESS-Datenbank

**Hendrik** · 11.11.2002, 09:02

@Hr. Kosch 
treffen o.g. Aussagen auch f�r SQL-Server zu? 
Ich verwende TBetterADODataSet und SQL-Server 2000 sowie D5E. 
Hendri

**Andreas Kosch** · 11.11.2002, 09:07

Hallo,

ein SQL-Server wird normalerweise generell �ber eine optimistische Sperre angesprochen, da dort nur der Prozess des SQL Servers selbst Zugriff auf die Datenbankdatei hat. Im Fall von ACCESS (datensatzorientierte Desktop-Datenbank) greift jeder Client direkt auf die physische Datenbankdatei zu, so dass dort im Mehrbenutzerbetrieb pessimistische Sperren notwendig sind, um die Datenintegrit�t zu sch�tzen.

Im Fall des SQL Server ist die CursorLocation clUseClient die bessere Wahl, so dass pessimistische Sperren (�ber die Transaktion) erst gar nicht verf�gbar sind. Da TBetterADODataSet sowohl den Provider (JET Engine) als auch die CursorLocation (clUseServer) pr�ft, ist der TBetterADODataSet-Mechanismus beim Microsoft SQL Server immer deaktiviert. Ein Mehrbenutzerkonflikt macht sich daher erst beim Post der �nderung bemerkbar.
&#10

**Mario.Noack** · 14.11.2002, 17:18

Hallo,
genau hier haben wir ein Problem mit einer Accesstabelle wenn ein AutoInc-Feld drin ist. Sobald die Datenbank in den Edit-Modus gehen soll, kommt die Meldung, "Feld kann nicht akutalisiert werden". Bei Insert klappt alles... (AdoDataset / BetterAdoDataSet402)...
Hat jemand noch eine Idee?
Sch�ne Gr��e, Mario Noac

**Andreas Kosch** · 15.11.2002, 08:24

Hallo,

>..mit einer Accesstabelle wenn ein AutoInc-Feld drin ist..

dieser Sonderfall wird von TBetterADODataSet extra gepr�ft.
Wenn die erste Spalte der Tabelle kein AUTOINCREMENT-Feld ist, das von der Jet Engine automatisch hochgez�hlt wird, schreibt TBetterADODataSet den alten Wert neu in diese 1. Spalte. Wird allerdings ein AUTOINCREMENT-Feld vorgefunden, passiert dies mit der 2. Spalte der Tabelle.
<pre>
Procedure TBetterADODataSet.InternalEdit;
Begin
Inherited;
//This code was provided by Harry Van Tassel.
If (CursorLocation=clUseServer) And
(LockType=ltPessimistic) And
CanModify And
Not(BOF And EOF) And
(Pos('JET.OLEDB', UpperCase(Connection.Provider))>1) Then
Begin
UpdateCursorPos;
FLockCursor:=Nil;
FLockCursor:=Recordset.Clone(ADOInt.adLockUnspecif ied);
With FLockCursor Do Begin
BookMark:=RecordSet.BookMark; {sync the cloned cursor}
If (Fields[0].Properties['ISAUTOINCREMENT'].Value=False) Then
Fields[0].Value:=Fields[0].Value
Else If (Fields.Count>0) Then
Fields[1].Value := Fields[1].Value;
End; //With
End;
End;
</pre>
Wenn die eigene Tabelle auch in der 2. Spalte keinen geeigneten Datentyp nutzt, muss man 
a) entweder den Sourcecode von TBetterADODataSet �ndern, oder 
b) zu meinem manuellen Weg wechseln

Announcement

ADO / Access / ClClient / Multiuser

ADO / Access / ClClient / Multiuser

Comment

Comment

Comment

Comment

Comment