DataSnap mit mehreren Datenbanken

[Sir Rufo]

@himitsu

Warum ein try .. except wo ein try .. finally reicht?
Vor allem im letzten Beispiel lieferst du bei einer Exception eine ungültige Referenz zurück.

So ist es sauber:

Delphi-Quellcode:

LDataSet := TFDQuery.Create;
try
  ...
  Result := LDataSet;
  LDataSet := nil;
finally
  LDataSet.Free;
end;

[himitsu]

Weil das logischier und vorallem verständlicher ist?
> Wenn es knallt, dann gibt es wieder frei?

Andersrum muß man vorher erstmal gucken/wissen was damit gemacht wurde (an wen anderes zuweisen und auf nil setzen),
aber auf den ersten Blick heißt es erstmal nur
> Gib es immer frei, selbst wenn es erfolgreich war.

Zitat von Sir Rufo:

Vor allem im letzten Beispiel lieferst du bei einer Exception eine ungültige Referenz zurück.

Nein, denn bei einer Exception kommt der Code bei der Zuweisung nicht mehr vorbei.

[edit]
Ups, hatte was vergessen, aber das hat ja keiner gemerkt.
(Copy&Paste im kleinen DP-Beitragseditor ist das Beste)

[Kostas]

Hallo zusammen,

ich habe nun ein neues DataSnapServer-/Client Projekt aufgesetzt und dabei das Prinzip Connection Pooling eingesetzt.
Ein DataSet kann auch "ThreadSave" vom Client abgerufen werden. Es scheint alles zu funktionieren.


Wenn der Server ein DataSet bereit stellt, darf die Connection am Ende nicht beenden werden.
Ich darf auch nicht die Connection und die Query am ende auf Free setzen. Ist das so in Ordnung?
Setze ich es auf Free, bekommt der Client nix.

Ist die Methode soweit ausreichend ThreadSave?

Delphi-Quellcode:

function TdmDALZMI.GetBau(BauNr: integer): TDataSet;
var
  oConn:  TFDConnection;
  oQuery: TFDQuery;
begin
  oQuery := nil;

  oConn  := TFDConnection.Create(nil);
  oQuery := TFDQuery.Create(nil);
  try
    TThread.Synchronize(nil, procedure
    begin
      oConn.ConnectionDefName := ZMIConnectionDefName;  //<<<<< Der ConnectionManager möchte unbedingt über ConnectionDefName gebunden werden damit Pooling funktioniert.
      oQuery.Connection := oConn;
      oQuery.FetchOptions.AutoFetchAll := afAll;  //<< Alle Record sollen vollständig abgerufen werden

      oQuery.SQL.Text := 'SELECT * FROM BAU WHERE BAUNR = :BAUNR';
      oQuery.Params[0].AsInteger := BauNr;
      oQuery.Open;
//      oConn.Close;     //<<<<<<<<<<<<<<<< Ist das OK?
    end);

    result := oQuery;
  finally
//    oQuery.Free;      //<<<<<<<<<<<<<<<< Ist das OK?
//    oConn.Free;       //<<<<<<<<<<<<<<<<   
  end;

end;

Clientseitig wird das DataSet so abgerufen und in eine TFDMemTable copiert:

Delphi-Quellcode:

procedure TdmZMI.GetBauDataSet(BauNr: integer);
var
  LZMIClient: TdmServerMethodsZMIClient;
  LDataSet: TDataSet;

begin
  LZMIClient := TdmServerMethodsZMIClient.Create(dmClientContainer.CMCSQLConnection.DBXConnection);
  try
    LDataSet := LZMIClient.GetBau(BauNr);
    mtBau.Active := False;
    mtBau.CopyDataSet(LDataSet, [coStructure, coRestart, coAppend]);
    mtBau.Open;
  finally
    LZMIClient.Free;
  end;

end;

Gruß Kostas

[himitsu]

Die Query kann so vom DataSnap (Result + OwningResults) freigegeben werden,
aber wer gibt die Connection frei?

Entweder du leitest die Query ab und baust die Connection dort ein, oder du benutzt die Query als Owner.

Delphi-Quellcode:

Result := TFDQuery.Create(nil);
try
  oConn := TFDConnection.Create(Result);
  oConn.ConnectionDefName := ZMIConnectionDefName;
  Result.Connection := oConn;
  Result.FetchOptions.AutoFetchAll := afAll;
  Result.SQL.Text := 'SELECT * FROM BAU WHERE BAUNR = :BAUNR';
  Result.Params[0].AsInteger := BauNr;
  Result.Open;
except
  Result.Free;  // freigeben, wenn es beim Erstellen und vorallem im Open Probleme gab. (Tabelle/Feld nicht gefunden)
  raise;
end;

Und natürlich darf die Query am Ende nicht freigegeben oder geschlossen werden, denn es soll ja deren Inhalt am Ende noch übertragen werden und dafür mit die Query existieren und vorallem auch Daten enthalten.

[Kostas]

Hallo himitzu,

das mit dem Result als TFDQuery schein nicht zu funktionieren. Der Compiler
meckert, "Symbol Result kann nicht erfasst werden" innerhalb der anonymen Thread Methode.

Delphi-Quellcode:

function TdmDALZMI.GetBau(BauNr: integer): TDataSet;
var
  oConn:  TFDConnection;
//  oQuery: TFDQuery;
begin
//  oQuery := nil;
  Result := TFDQuery.Create(nil);

  oConn  := TFDConnection.Create(nil);
//  oQuery := TFDQuery.Create(nil);
  try
    TThread.Synchronize(nil, procedure
    begin
      oConn.ConnectionDefName := ZMIConnectionDefName;
      Result.Connection := oConn;   //<<<geht nicht 
      Result.FetchOptions.AutoFetchAll := afAll;

      Result.SQL.Text := 'SELECT * FROM BAU WHERE BAUNR = :BAUNR';
      Result.Params[0].AsInteger := BauNr;
      Result.Open;
//      oConn.Close;
    end);

//    result := oQuery;
  except
    result.Free;
//    oConn.Free;
  end;

end;

Wegen dem Connection Objekt, als ich umgestellt habe, bin ich nach dem Beispiel Pooling von FireDAC
vorgegangen. Hier wird eine Connection instanziiert allerdings auch wieder freigeben!

Mit nicht freigeben von Objekten bin ich nicht Sattelfest. Ich kann das noch nicht greifen.
Aber wenn es funktioniert, ist mir das auch recht.
Eigentlich hätte ich erwartet dass das Connection Objekt über den ConnectionManager gemanagt wird.

Delphi-Quellcode:

procedure TConnectThread.Execute;
var
  oConn:  TFDConnection;
  oQuery: TFDQuery;
  i: Integer;
begin
  oConn  := TFDConnection.Create(nil);
  oQuery := TFDQuery.Create(nil);
  try
    oQuery.Connection := oConn;
    oConn.ConnectionDefName := FForm.cbDB.Text;
    for i := 1 to 50 do begin
      oQuery.SQL.Text := 'select count(*) from {id Region}';
      oQuery.Open;
      oConn.Close;
      Synchronize(FForm.Executed);
    end;
  finally
    oConn.Free;
    oQuery.Free;
  end;
end;

Leider kann ich nicht nachvollziehen wie du es gemeint hast mit Query als Owner.
Wenn es deine Zeit erlaubt, würdest du das bitte kurz beschreiben.


Gruß Kostas

[himitsu]

Wenn eine Variable nicht erfasst werden kann, dann mit einer TempVariable dazwischen arbeiten.

Mit Owner meinte ich das so

Delphi-Quellcode:

oQuery := TFDQuery.Create(nil);  // in der Methode mit Try-Except gesichert und danach wird DateSnap der Owner des Result
oConn := TFDConnection.Create(oQuery);  // die FDQuery übernimmt die Kontrolle der Freigabe

Hier kommt doch nur noch ConnectionDefName von außerhalb.
Alles Andere ist intern und wäre somit threadsave.
Wenn der Wert ConnectionDefName aus einem String kommt (die sind beim Lesen threadsave, solange es keine externen Änderungen gibt), dann geht das auch so,
ansonsten müsste man eigentlich nur noch diesen Zugriff absichern.

[Kostas]

Hallo himitzu,

jetzt läuft alles einwandfrei und Sau schnell.
Ohne die Sache mit dem Owner, konnte ich maximal 50 Anfragen stellen da die Default Connections Anzahl bei
50 steht. Somit ist klar, die Connection waren aktiv! Mit dem Owner gibt es nun keine Limitierung.
Zugleich habe ich die Bestätigung dass das Query Objekt von "Geisterhand" selbstständig eliminiert wird
nach dem Transfer da damit auch die Connection eliminiert wird.

Das ist doch wie Weihnachten und Ostern an einem Tag.
Ich bin dir sehr dankbar und weis das auch zu schätzen.

Gruß Kostas