DataSnap Client connection über FireDAC

[Kostas]

Hallo Zusammen,

ich arbeite gerade dieses Tutorial durch.
http://docwiki.embarcadero.com/RADSt...Base-Tutorial)

Dabei werden DBX Komponenten verwendet(TSQLConnection) die ich gerne durch FireDAC ersetzt würde. Ich habe eine TFDPhysDSDriverLink Komponente auf die Form gelegt wie in diesem Dokument beschrieben.

ms-help://embarcadero.rs_xe6/rad/Herstellen_einer_Verbindung_zum_DataSnap-Server_(FireDAC).html

Wo trage ich nun die beschriebenen Parameter wie Servername, Port u.s.w. zur Laufzeit ein?


Gruß Kostas

[mkinzler]

In der Connection-Komponente

[Kostas]

Hallo Markus,

das habe ich zunächst auch versucht und konnte mich auch mit dem DataSnapServer verbinden.
Doch im Tut. folgt nach der SQLConnection eine SqlServerMethod die findet unter SQLConnection natürlich nicht die FDConnection. Das hat mich an dieser Stelle irritiert.
Wie hängt das bitte zusammen? Oder ist es so zu verstehen, Clientseitig muss ich wenn ich
DataSnap nutzen möchte due DBX Komponenten verwenden?

Gruß Kostas

[Uwe Raabe]

Ganz ehrlich? Wenn du mit DataSnap arbeiten willst, dann nutzt du auch bei XE6 besser noch die DBX Komponenten. Der DataSnap-Support bei FireDAC ist m.E. leider noch nicht ausgereift genug für eine brauchbare Anwendung. Das wird sich aber in den kommenden Delphi-Versionen sicher noch verbessern.

In den Beispielen unter Object Pascal\DataSnap\FireDACJSONReflect findest du allerdings ein kleines Beispiel.

[Kostas]

Besten Dank für den Hinweis Uwe.

Darf ich dich fragen wie du DataSnap generell einschätzt? Ist es geeignet im produktiven Umfeld? Ich hatte in XE2 meine ersten Versuche. Das Hauptproblem war damals wenn ein Client
mit unzuverlässiger Connection wie Mobile Anwendungen die Connection verloren hat, hat
das komplette System gesponnen. Die Connection konnte also nicht mehr aufgenommen werden und mindestens die Client Applikation musste neu gestartet werden. Ist dir bekannt ob
in diesem Bereich sich DataSnap weiterentwickelt hat? Ich spreche bewusst instabile Connections an da ich eine Anforderung habe einen relativ einfachen Client zu schreiben
welcher auf ein Android Smartphone und auf ein IPhone5 laufen soll.

Gruß Kostas

[jaenicke]

Wir nutzen DataSnap ebenfalls. Abbrechende Verbindungen verwalten wir selbst. Sprich wir haben einen Wrapper um die Clientmethoden, die die Verbindung wieder aufbauen, wenn der Aufruf durch einen Verbindungsabbruch fehlschlägt.

Der Transfer von Datasets über FireDACJSONReflect funktioniert sehr gut und ist gerade bei vielen kleinen Datenbanktabellen um ein vielfaches schneller als vorher via DBX. Ich hoffe, dass da noch mehr kommt, aber gut nutzbar ist das auf jeden Fall.

Da serverseitig eigene Sessions auch das Datenbankhandling übernehmen, ist auch dort ein Verbindungsabbruch kein Problem solange die Session beim Reconnect noch da ist. Da man bei FireDACJSONReflect die Verbindung zwischen den Komponenten selbst regelt, macht DataSnap da auch keinen Strich durch die Rechnung wie leider an manchen anderen Stellen.

Wichtig beim Reconnect:
Die Clientmethoden-Klasse muss neu erstellt werden, ansonsten funktioniert diese danach nicht mehr...
Vielleicht ist das das Problem gewesen, auf das du gestoßen warst.

[Uwe Raabe]

Erganzend dazu: Der ClientCallbackManager braucht einen kleinen Patch, damit er nach einem Verbindungsabbruch wieder funktioniert.

[Kostas]

Danke Sebastian für den Hinweis.

Ich fange jetzt wirklich frisch an und versuche mich durch die Tuts und Dokus.
Dein Hinweis kann ich noch nicht werten, ich bin noch nicht so weit.
Möglicherweise meinst du das:

Aus den aktuellen Tut: http://docwiki.embarcadero.com/RADSt...Base-Tutorial)

Delphi-Quellcode:

procedure TfrClientMain.Button3Click(Sender: TObject);
var
  myServer: TUn_ServerModuleClient;
  von,bis: TDateTime;
begin
  SQLConnection1.Open;

  myServer := TUn_ServerModuleClient.Create(SQLConnection1.DBXConnection);
  try
    Label1.Caption := myServer.callStoredProcedureAuswertung(StrToDateTime(Edit1.Text),StrToDateTime(Edit2.Text));
  finally
    if SQLConnection1.Connected
    then SQLConnection1.close;
    myServer.free;
  end;

end;

Meinst du das die Instanz von "myServer" nach einem Abbruch neu erzeugt werden soll?
In diesem Fall wäre das recht einfach. Ich nutze hier eine Methode "callStoredProcedureAuswertung" die der DataSnapServer bereitstellt. Es ist aber
auch so dass der Client DataSets konsumiert die über DataSetProvider-ClientDataSet
bereitgestellt werden. Auf der Form gibt es auch eine DSProviderConnection dessen Connection
ich zumindest zur Designtime nicht disconnecten kann.

Sorry für die unqualifizierte Beschreibung, wie gesagt, ich fange wieder frisch an.

Gruß Kostas

[Kostas]

Zitat:

Zitat von Uwe Raabe (Beitrag 1269596)

Erganzend dazu: Der ClientCallbackManager braucht einen kleinen Patch, damit er nach einem Verbindungsabbruch wieder funktioniert.

Das ist doch sehr interessant. Danke für den Hinweis Uwe.

[jaenicke]

Zitat:

Zitat von Kostas (Beitrag 1269600)

Meinst du das die Instanz von "myServer" nach einem Abbruch neu erzeugt werden soll?

Ja, genau.

Zitat:

Zitat von Uwe Raabe (Beitrag 1269596)

Erganzend dazu: Der ClientCallbackManager braucht einen kleinen Patch, damit er nach einem Verbindungsabbruch wieder funktioniert.

Welchen meinst du?

Callbacks habe ich zumindest aus Thin Clients durch erneute Verbindungsversuche wiederherstellen können ohne dass ich etwas geändert hätte.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1269624)

Zitat:

Zitat von Uwe Raabe (Beitrag 1269596)

Erganzend dazu: Der ClientCallbackManager braucht einen kleinen Patch, damit er nach einem Verbindungsabbruch wieder funktioniert.

Welchen meinst du?

Callbacks habe ich zumindest aus Thin Clients durch erneute Verbindungsversuche wiederherstellen können ohne dass ich etwas geändert hätte.

Den Patch brauchte ich in einer XE3 App und ich habe es unter XE6 noch nicht wieder probiert, denke aber es ist dort immer noch so.

Kurz: Bei verbundenem Client den Server neu starten. Nun funktionieren die Callbacks nicht mehr und der Client kann die auch nicht mehr registrieren. Das lässt sich nur mit einem Neustart des Clients beheben (genauer mit dem Neuerzeugen des CallbackManagers).

Lang: In TDSClientCallbackChannelManager.CloseClientChannel wird das interne Feld FStopped gesetzt, wenn der Server die Verbindung beendet. Dabei werden aber die Callbacks nicht freigegeben. Ruft man dann TDSClientCallbackChannelManager.CloseClientChannel auf, ist der ExcuteRemote-Aufruf zum einen vollkommen überflüssig (die Verbindung ist ja definitiv weg) und läuft zum anderen in einen Timeout (kostet unnütz Zeit). Das nachfolgende FLocalCallbackRepo.Clear und das Anpassen der Statevariablen wird nicht mehr aufgerufen. Die Callbacks bleiben also im Dictionary und man kann Sie somit nicht mehr neu anlegen (RegisterCallback sieht, die sind schon da und gibt false zurück). Die alten Callbacks funktionieren aber nicht mehr, weil sie beim Server nicht mehr registriert sind (der wurde ja neu gestartet).

Der Patch besteht im Wesentlichen darin, bei FStopped das ExecuteRemote zu überspringen und trotzdem das FLocalCallbackRepo.Clear aufzurufen. Bei XE3 liegt der Code in Datasnap.DSHTTPCommon und bei XE6 in Datasnap.DSCommon.

[jaenicke]

FStopped finde ich nicht, ich vermute du meinst State auf Stopped? Das Problem ist dann aber klar, ja.
Der Code in CloseClientChannel sieht in XE3 und XE6 identisch aus.

Jetzt wo du es sagst, kann ich mich auch erinnern, dass ich an der Stelle schon einmal ein Problem hatte, ich hatte es mir nur nicht genauer angeschaut.

Gibt es dazu schon einen QC Eintrag? Ich konnte nämlich eben bei einer schnellen Suche keinen finden.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1269634)

FStopped finde ich nicht, ich vermute du meinst State auf Stopped?

FStopped ist ein Feld von TDSClientCallbackChannelManager und wird in NotifyChange gesetzt. Da es strict private ist, lässt sich das leider auch nicht mit einer abgeleiteten Klasse fixen.

Zitat:

Zitat von jaenicke (Beitrag 1269634)

Der Code in CloseClientChannel sieht in XE3 und XE6 identisch aus.

Bis auf die Tatsache, daß in XE3 die lokale Variable Status nicht initialisiert wird und damit einen unbestimmten Wert enthält wenn State <> ctsStarted ist. In XE6 wird sie mit False vorbelegt, was meiner Meinung nach ungünstig ist, aber das ist vielleicht auch Geschmackssache. Ich finde es intuitiver, wenn auch bei State <> ctsStarted ein CloseClientChannel mit true durchläuft und der State hinterher auf ctsStopped steht, insbesondere wenn der State vorher auf ctsFailed stand. Wichtig ist aber, daß Status bei FStopped auf True gesetzt wird, damit auch aufgeräumt wird.

Zitat:

Zitat von jaenicke (Beitrag 1269634)

Das Problem ist dann aber klar, ja.Gibt es dazu schon einen QC Eintrag? Ich konnte nämlich eben bei einer schnellen Suche keinen finden.

:oops: Ich muss zu meiner Schande gestehen, daß ich es versäumt habe, einen simplen Testfall aufzubereiten. Takahashi san ist da bekannterweise etwas anspruchsvoll. Ich gelobe aber Besserung.