Delphi/Centura

[Gerhard Duerr]

ich möchte von delphi5 aus über ADOCommand, ADOConnect und ADODataset (ohne TADOTable, -Query) auf die sqlbase zugreifen. danach daten über select...where...auslesen und in einer tabelle darstellen. das problem ist, dass wenn ich ein dbgrid nehme und den dbnavigator, bei jeder änderung in der tabelle sofort ein post an die db geschickt wird und die änderungen darin gespeichert werden. ich möchte die transaktionskontrolle aber selbst in die hand nehmen - komme aus der gupta/centura-ecke und bin von da aus verwöhnt, was das dortige tblWindow anbelangt. -
wer kann mir helfen ?

[Andreas Kosch]

Hallo,

wo liegt das Problem? Über die TADOConnection-Komponente können doch die Methoden <b>StartTransaction</b>, <b>CommitTrans</b> oder <b>RollbackTrans</b> aufgerufen werden. Und über die TADOConnection-Eigenschaft <b>TransIsolation</b> darf man auch den Isolation Level der Transaktion festlegen.

Da TADOConnection diese Aufrufe sofort an das Connection-Objekt von ADO weiterreicht, ändert sich nichts, wenn auf TADOConnection verzichtet wird und man direkt auf das Connection-Objekt zugreift.

ADO stellt über <b>ltBatchOptimistic</b> sogar einen Weg zur Verfügung, der alle Schreibzugriffe erst lokal auf dem Client zwischenspeichert. Somit muss man die Transaktion erst gar nicht über einen längeren Zeitraum offen halten, sondern kann selbst festlegen, zu welchen Zeitpunkt über den Aufruf der Methode <b>UpdateBatch</b> alle Datensätze auf einmal in die Datenbank geschrieben werden.
&#10

[Gerhard Duerr]

Vielen Dank für Ihre prompte Antwort.

Würden Sie empfehlen, eigene Komponenten (stellvertreten für DBNavigator und DBGrid) für die Transaktionssteuerung zu bilden ?
G. Dür

[Andreas Kosch]

Hallo,

nein, ich glaube nicht, dass dies irgend einen Vorteil hätte

[Gerhard Duerr]

hallo hr. kosch,
soweit funktioniert der connect zur sqlbase, das füllen eines
dbgrid und das navigieren über den dbnavigator funktioniert ebenfalls.

das problem ist folgendes:
bei einer änderung im dbgrid (eine zelle) und nach dem springen in die nächste zeile, wird die änderung sofort in die datenbank geschrieben.

frage:
wie kann ich diesen mechanismus umgehen und die steuerung selbst in die hand nehmen

[Andreas Kosch]

Hallo,

dazu muss das lokale RecordSet-Objekt im Batch-Modus betrieben werden (siehe <b>ltBatchOptimistic</b>-Hilfeseite von Delphi). In diesem Fall puffert ADO alle Änderungen lokal im Arbeitsspeicher, erst beim Aufruf von <b>UpdateBatch</b> werden alle Änderungen auf einmal zurück in die Datenbank geschrieben

[Gerhard Duerr]

hallo,
ich habe nun das lokale recordset im batch-modus geöffnet:
with ADODataSet2 do begin
CursorLocation := clUseServer;
CursorType := ctKeyset;
LockType := ltBatchOptimistic;
CommandType := cmdText;
CommandText := 'select * from ADRESSEN';
Connection := ADOConnection1;
Open;
end;

und meine änderungen durchgeführt. diese werden im dbgrid auch angezeigt/aktuallisiert.
danach schreibe ich die änderungen in die db:

procedure TForm1.ADODataSet2WillChangeRecord(DataSet: TCustomADODataSet;
const Reason: TEventReason; const RecordCount: Integer;
var EventStatus: TEventStatus);
begin
ADODataSet2.UpdateBatch(arAll);
ADOConnection1.CommitTrans;
end;

melde mich dann von der db ab und wieder an. ergebnis:
daten wurden nicht übernommen.
eigentlich müsste es doch so funktionieren ?

was mir dann noch nicht klar ist - wo und wie muss die sql-anweisung für ein update (auch für ein insert) definiert werden? - nach sqlwindows-art (update adressen set spalte1 = :tblAdressen.spalte1,...).

vielen dank mal im vorau

[Andreas Kosch]

Hallo,

bei diesem Modus muss ein <b>clUseClient</b>-Cursor verwendet werden. Die Methode <b>UpdateBatch</b> wird nur einmal am Ende aufgerufen, aber nicht bei jedem Datensatz. Das RecordSet-Objekt von ADO generiert alle SQLs automatisch. Das folgende Beispiel demonstriert den Einsatz:
<pre>
{ ************************************************** *******************
Autor : Andreas Kosch
Compiler : Delphi 5 UpdatePack#1
Betriebssystem : Windows 2000
Datum : 19.09.2000
Beschreibung : ADO BriefCase-Modell, Änderungen offline
durchführen und erst später in der originalen
SQL Server 7-Datenbank einspielen
************************************************** ******************** }

unit ADOBriefCaseFrm;

interface

uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
ComCtrls, ExtCtrls, DBCtrls, Db, Grids, DBGrids, ADODB, StdCtrls;

type
TForm1 = class(TForm)
RadioGroup1: TRadioGroup;
Label1: TLabel;
StaticTextFile: TStaticText;
ADOConnection1: TADOConnection;
ADODataSet1: TADODataSet;
DBGrid1: TDBGrid;
DataSource1: TDataSource;
ADODataSet1ID: TAutoIncField;
ADODataSet1Name: TStringField;
ADODataSet1Vorname: TStringField;
ADODataSet1Ort: TStringField;
ADODataSet1eMail: TStringField;
DBNavigator1: TDBNavigator;
StatusBar1: TStatusBar;
ButtonUpdateBatch: TButton;
ButtonCancelBatch: TButton;
procedure RadioGroup1Click(Sender: TObject);
procedure ButtonUpdateBatchClick(Sender: TObject);
procedure ButtonCancelBatchClick(Sender: TObject);
private
{ Private-Deklarationen }
FOnline : Boolean;
public
{ Public-Deklarationen }
end;

var
Form1: TForm1;

implementation

{$R *.DFM}

procedure TForm1.RadioGroup1Click(Sender: TObject);
begin
FOnline := False;
case RadioGroup1.ItemIndex of
0 : begin
StatusBar1.Panels[0].Text := '';
StatusBar1.Panels[1].Text := '';
if ADODataSet1.Active then
begin
ADODataSet1.SaveToFile(StaticTextFile.Caption);
ADODataSet1.Active := False;
end;
ADOConnection1.Connected := False;
end;
1 : begin
ADODataSet1.Active := False;
ADOConnection1.Connected := False;
ADODataSet1.LoadFromFile(StaticTextFile.Caption);
ADODataSet1.Active := True;
StatusBar1.Panels[0].Text := Format('%d Datensätze',
[ADODataSet1.RecordCount]);
StatusBar1.Panels[1].Text := 'Offline: ' + StaticTextFile.Caption;
end;
2 : begin
ADOConnection1.Connected := True;
ADODataSet1.Active := True;
StatusBar1.Panels[0].Text := Format('%d Datensätze',
[ADODataSet1.RecordCount]);
StatusBar1.Panels[1].Text := 'Online SQL Server 7';
FOnline := True;
end;
end;
ButtonUpdateBatch.Enabled := FOnline;
ButtonCancelBatch.Enabled := FOnline;
end;

procedure TForm1.ButtonUpdateBatchClick(Sender: TObject);
begin
// Objektinspektor: ADODataSet1.MarshalOptions = moMarshalModifiedOnly
ADODataSet1.UpdateBatch;
end;

procedure TForm1.ButtonCancelBatchClick(Sender: TObject);
begin
ADODataSet1.CancelBatch;
end;

end.
</pre&gt

[Gerhard Duerr]

hallo,
vielen dank für ihr beispiel; habe es entsprechend meiner anwendung abgeändert. funktioniert prima. können sie literatur empfehlen, die die transaktionsbehandlung delphi/ado speziell behandelt - vielleicht etwas aus den vergangenen entwicklertagen ? (client/server und com habe ich bereits von ihnen).

wie schon erwähnt komme ich aus der centura-welt und befasse mich mit delphi erst seit einem 3/4 jahr. hier ist es doch etwas anderst und es macht mich etwas nervös, wenn ich die sql-statments nicht selbst "basteln" kann.
das sie selbst centura kennen verstehen sich mich vielleicht.

gruss
g. duer

[Andreas Kosch]

Hallo,

in meinem <i>COM/DCOM/COM+</i>-Buch gehe ich kurz auf die Grundlagen von ADO ein, da in den MTS/COM+-Beispielen der Zugriff auf den SQL Server 7/2000 über ADO läuft. Ein eigenständiges Buch über das Thema "Delphi und ADO" ist für Ende dieses Jahres geplant, vorher kommt ein Buch zum Thema "Delphi und der InterBase 6 + IBX".<br>
Meine Konferenz/Entwicklertage-Unterlagen zum Thema ADO bestehen zur Zeit nur aus vielen bebilderten HTML-Dateien und sind einzeln nicht erhältlich

[Gerhard Duerr]

vielen dank hr. kosch für ihre auskünfte und hilfestellungen. sie habe mir prima weitergeholfen