Wer nutzt denn alles DataSnap?

[himitsu]

Mal eine ganz einfache Frage,

Nutzt ihr DataSnap und wenn ja, was macht ihr denn so alles damit?


Also, wenn ich dieses so nutze, wie es in vielen Tutorials beschrieben wird
und wenn ich etwas mehr möchte, als mit dieser komische Wizard an zusammenklickbarem Code zur Verfügung stellt, dann hab ich das Gefühl, dieses DataSnap wäre nicht für einen produktiven Einsatz geeignet. :gruebel:

Jedenfalls wenn ich bedenke, daß es hier und da einige Ungereimtheiten gibt, wie z.B. Stream, welche einfach mal so nicht übertragen werden und von den Speicherlecks ganz zu schweigen.

z.B. die Sache mit dem Callback:
So wie es Bob macht, da wird das Result vom Execute nicht freigegeben und auch beim übergebenen Parameter muß man wohl etwas aufpassen.
http://edn.embarcadero.com/article/40356

Außer von Bob gibt es leider kaum Quellen und wenn, dann sieht es so aus, als wenn es ihm fast alle einfach nur blind nachmachen. :stupid:

[mirage228]

Hey,

Ich wollte es mir mal anschauen, bis mir auffiel, dass es in meiner Professional-Version gar nicht dabei ist ;-)
Es hatte sich zumindest interessant angehört, aber die Probleme, die Du ansprichst hören sich ja nun nicht so gut an, zumal ja auch eigentlich recht rege Werbung für DataSnap gemacht worden ist...

Viele Grüße

[himitsu]

Jupp, privat kann ich's auch nicht nutzen, aber auf Arbeit hab'sch 'nen großes XE zur Verfügung.
Hatte aber dennoch mal versucht unser DataSnap-Modul in meinem 2010 laufen zu lassen, so in der Hoffnung, daß nur die Wizards fehlen, aber alle nötigen Dateien dennoch dabei sind ... dem war leider nicht so. :stupid:

Und jupp, Werbung wird viel gemacht, aber wenn man sich mal in der DP und in Google umschaut, dann scheint es so, als wenn es eigentlich keiner nutzt, da man fast garnichts dazu findet.

[taveuni]

Data Snap hatten wir uns angeschaut als wir ein erstes grosses Multi Tier Projekt realisieren mussten.
Glücklicherweise sind wir damals über RemObjects gestolpert.
Dieses Framework ist ausserordentlich mächtig.
Ausserdem ist es als natives Delphi VCL Framework und als .net Framework erhältlich.
Wir haben nun schon diverse Projekte mit gemischten Delphi Clients / .net Servern und
umgekehrt realisiert. Wenn Du da mal angebissen hast kommst Du nicht mehr davon los.

Neuerdings gibts das Framework auch für Mac OSX.
Multiplatform in diesem Sinne ist also greifbar.

Allerdings kostet's natürlich eine Kleinigkeit.

[DSCHUCH]

ich vermute mal ihr nutzt data abstract. das ist eine art middle tier bzw mapping für db-zugriff, korrekt? eigene funktionen damit abzubilden scheint mir zumindest im video nicht vorzukommen. auch benötigt man ja häufig unabhängig der datenbank funktionen welche zB einfach nur rechnen und ein ergebnis zurückgeben.

eine weitere anforderung ist ja zB caching. der application server soll daten zwischencachen damit die datenbank nicht ständig durch abfragen belastet wird, welche immer das gleiche ergbnis an die clients liefert (statusinformation). wenn es änderungen an daten gibt, meldet der db-server dies dem app-server, dieser fragt die daten neu ab und meldet den clients, dass diese ihre neuen informationen jetzt beziehen können.

[stahli]

@ himitsu:
Nur der Vollständigkeit die heutige eMail...

@ DSCHUCH:
So hatte ich das auch interpretiert und wenig verstanden (insb. für welche Anwendungsfälle so etwas geeignet ist) :duck:
Erst dachte ich, es wäre ein Ersatz/Nachfolger von ECO aber das ist es wohl doch nicht.

[himitsu]

@stahli: Jupp, hab ich gesehn.
Ich glaub der beobachtet mich ... Zum Mittag hab ich seinen Namen erwähnt und kurz darauf kommt eine Mail. :lol:
Ansonsten, nutze ich auch schon einige seiner Veröffentlichungen, zu diesem Thema.
Och, als Erstes wird dann erstmal Mister Eissing genervt, wenn wir ihn bald sehn :twisted:

[add]
soviele persönliche Information für eine kleine PDF? :shock:
http://forms.embarcadero.com/forms/A...SnapWhitepaper

[Phoenix]

Zitat:

Zitat von DSCHUCH (Beitrag 1081996)

ich vermute mal ihr nutzt data abstract. das ist eine art middle tier bzw mapping für db-zugriff, korrekt? eigene funktionen damit abzubilden scheint mir zumindest im video nicht vorzukommen. auch benötigt man ja häufig unabhängig der datenbank funktionen welche zB einfach nur rechnen und ein ergebnis zurückgeben.

Das Mapping ist nur ein kleiner Aufgabenteil von DataAbstract. Der Schwerpunkt liegt selbstverständlich auf der Implementierung eigener Business-Logik in einer skalierbaren Schicht. Du kannst eigene Funktionen sowohl im Code als auch mittels Scripting implementieren. Wahlweise eins von beidem oder auch in Kombination. Je nach belieben. Scripting hat hierbei den Vorteil, dass die Scripte auch zur Verifizierung noch an den Client übertragen werden können und dort eine Vor-prüfung durchführen können um unnötiges Übertragen von Daten zu verhindern.

Zitat:

Zitat von DSCHUCH (Beitrag 1081996)

eine weitere anforderung ist ja zB caching. der application server soll daten zwischencachen damit die datenbank nicht ständig durch abfragen belastet wird, welche immer das gleiche ergbnis an die clients liefert (statusinformation). wenn es änderungen an daten gibt, meldet der db-server dies dem app-server, dieser fragt die daten neu ab und meldet den clients, dass diese ihre neuen informationen jetzt beziehen können.

Nicht wirklich. Cacheing macht in N-Tier-Umgebungen nahezu überhaupt keinen Sinn. Das Problem ist durch die Skalierbarkeit gegeben. Was für einen Sinn macht es, wenn der Application Server auf Maschine 1 Daten cached, die auf Maschinen 2, 3 und 4 gerade (ggf. gegensätzlich) verändert wurden? Um die Caches immer über alle Maschinen aktuell zu halten würde man so viel Synchronisierungs-Overhead erzeugen, das es keinen Sinn mehr machen würde das überhaupt in eine Separate Logik-Schicht auszulagern. Die Datenbank cached schon genug, daher besteht keine Notwendigkeit eine weitere Cache-Schicht einzuziehen. Um Datenbanken über die Verwendung größerer Cluster hinaus zu skalieren muss man anfangen, Daten zu partitionieren. Auch hier macht Cacheing gar keinen Sinn.

[MEissing]

Zitat:

Zitat von Phoenix (Beitrag 1082035)

Nicht wirklich. Cacheing macht in N-Tier-Umgebungen nahezu überhaupt keinen Sinn. Das Problem ist durch die Skalierbarkeit gegeben. Was für einen Sinn macht es, wenn der Application Server auf Maschine 1 Daten cached, die auf Maschinen 2, 3 und 4 gerade (ggf. gegensätzlich) verändert wurden? Um die Caches immer über alle Maschinen aktuell zu halten würde man so viel Synchronisierungs-Overhead erzeugen, das es keinen Sinn mehr machen würde das überhaupt in eine Separate Logik-Schicht auszulagern. Die Datenbank cached schon genug, daher besteht keine Notwendigkeit eine weitere Cache-Schicht einzuziehen. Um Datenbanken über die Verwendung größerer Cluster hinaus zu skalieren muss man anfangen, Daten zu partitionieren. Auch hier macht Cacheing gar keinen Sinn.

Diese Aussage ist in ihrer Pauschalität nicht richtig. Letztendlich geht es in jeder (Multi-Tier-) Anwendung um die Kosten für die Verarbeitung und Beschaffung der Daten. Nebenläufigkeiten (:-)) wie die Wahl zwischen Skalierbarkeit und Verfügbarkeit lasse ich hier erstmal weg:
Ein Cache kann durchaus Sinn ergeben, auch über verschiedene Instanzen eines Anwendungsservers hinweg. Sind die Kosten für bestimmte Datenbankabfragen besonders hoch, so implementiert man seit Jahren in den verschiedensten Anwendungen eine Caching-Protokoll, was diese Instanzen aktualisiert. Das ist nichts Neues.

Nimmt man dann doch noch die Verfügbarkeit des Gesamtsystems mit in die Waagschale, so ist es unerlässlich sich über ein zentrales Session-Management Gedanken zu machen. Spätestens da muss man sich über Caches und deren Synchronisation Gedanken machen.

Eine skalierbare Infrastruktur zu bauen ist nicht weiter kompliziert. Eine verfügbare Infrastruktur dagegen schon.

[Phoenix]

Rreden wir hier z.B. von Euren Foren? *scnr* ;-)

[himitsu]

Eigentlich wollten wir im ersten Schritt unser Dateimanagement auf Basis vom Datasnap auslagern, aber so wie es aussieht, ist das ja arschlangsam.
selbst wenn Server/Client auf dem selben Rechner direkt nebeneinander laufen, dann bekomm ich, via TCP/IP auf localhost, effektiv grade mal nur 1 MB/s raus.

Übers Netztwerk konnte ich jetzt leider noch nicht direkt testen, aber dort erwarte ich dann noch weniger.

[Daniel]

Welche Geschwindigkeiten bekommst Du denn in Eurem System, wenn Du die Dateien direkt via TCP/IP (z.B. mittels INDY) überträgst?
Sprich: Über welche Verzögerung durch DataSnap reden wir?

[himitsu]

TIdTCPServer/Client
5.000.000 Byte in 47 Milisekunden


DataSnap
2.251.872 Byte, nach Umwandlung in Base64 vielleicht 3 MB in 2,5 bis 3 Sekunden (knapp 150-200 ms sind dabei mein eigener Code)

[Phoenix]

Zitat:

Zitat von himitsu (Beitrag 1082236)

Eigentlich wollten wir im ersten Schritt unser Dateimanagement auf Basis vom Datasnap auslagern, aber so wie es aussieht, ist das ja arschlangsam.
selbst wenn Server/Client auf dem selben Rechner direkt nebeneinander laufen, dann bekomm ich, via TCP/IP auf localhost, effektiv grade mal nur 1 MB/s raus

Sowas ähnliches wurde auf Basis von RO/SDK schonmal umgesetzt: Case Study, Shell+ and Documents. Da gibts auch Beispiel-Sourcen dazu. Und von der Performance her ist das alles andere als langsam ;-)

[himitsu]

Nun sind wir ja fast fertig, aber wenn's so weitergeht, dann laufe ich auch über.

PS:
Endlich mal einer, der meine Probleme kennt
http://cc.embarcadero.com/item/27391
darin hab ich z.B. etwas gefunden, ala "große Streams übertragen" und so wie es aussieht, hatte er in etwa die selbe Idee, um das Problem zu lösen. :stupid:

Aber wie bei vielen anderen Codes (auch die von Dr. Bob) bin ich mir sicher, daß er nicht nach Speicherlecks ausschau gehalten hat.

Dr.Bob hat wenigstens fast nur die versteckten Speicherlecks übersehn, aber das sowas hier ist ja wohl eindeutig:

Delphi-Quellcode:

procedure TFrmMain.Button4Click(Sender: TObject);
var
  Sm: TDSServerMethodsClient;
begin
  Sm := TDSServerMethodsClient.Create
    (DMClientContainer.MyDSServer.DBXConnection);
  LBDateTime.Caption := DateTimeToStr(Sm.GetServerDateTime);
end;
// Sm wird jedesmal neu erstellt und nie freigegeben

procedure TFrmMain.Button9Click(Sender: TObject);
begin
  Result := TJSONFalse.Create;
  ...
  for i := 0 to LJSONObject.Size - 1 do
  begin
    ...
    Result := TJSONTrue.Create;  // wird immer wieder neu erstellt
  end;
  ...
end;

Da findet man schon fast nirgendwo ordentlich Hilfe, bei diesem suuuuuuper Produkt Namens DataSnap und wenn, dann muß man erstmal die Fehler beheben.

Nichts gegen diese Leute persönlich, aber wenn das wirklich jemand ernsthaft einsetzen würde, dann wären doch viele Fehler schon längst aufgefallen, oder meint ihr nicht. :?:
Wobei hier vermutlich der Garbage Collector im C#, PHP, Java oder wo DataSnap noch nutzbar ist, vermutlich derartige Speicherlecks behebt.

Auch wenn die Grundidee vom DataSnap ja garnicht mal soooooo schlecht ist.

[stahli]

Gibt es aktuelle Erfahrungen?

[himitsu]

Zitat:

Zitat von stahli (Beitrag 1108632)

Gibt es aktuelle Erfahrungen?

Bezüglich was genau?

> DataSnap ist recht langsam, vorallem wenn man auch mal größere Datenmengen übertragen will
> Stream-Parameter ab standardmäßig 29 KB (maximal 64 KB - 1 = Word) werden einfach nicht übertragen
> größere Stringparameter gehen aber (wenn auch noch langsamer) :shock:
> wenn man größere Datenmengen übertägt, steigt die CPU-Belastung schonmal ungewöhnlich stark an
> Nahezu alle Beispielcodes sind fehlerhaft, vorallem die wo JSON verwendet wird
(gut, eigentlich stammen fast alle diese speicherleckigen Codes von Dr. Bob und viele andere, der wenigen "selbsternannten DataSnap-Experten" kopieren eigentlich nur von ihm)

[stahli]

Zitat:

Zitat von himitsu (Beitrag 1108637)

Bezüglich was genau?

Ganz allgemeiner Art. Hätte nur mal gern auch etwas positives gelesen...

[jaenicke]

Das mit den Beispielcodes ist so eine Sache, man kann daran erkennen was da alles möglich ist. Wenn man das dann selbst umsetzt, ist das im Grunde kein Problem. Ganz ohne die Beispiele hätte ich sicher länger gebraucht...

Wir haben damit mittlerweile einiges gemacht und planen noch sehr viel mehr damit. Es gibt zwar immer mal wieder kleine Stolperstellen, aber bisher nichts wo wir nicht weitergekommen wären. Das funktioniert soweit ganz gut.

Das einzige wo wir noch nicht so sicher sind, ob unsere Lösungsansätze wirklich stabil laufen, ist das Management bei Verbindungsabbrüchen. Denn da habe ich in XE nicht wirklich viel dazu gefunden, ist aber für die intensiv genutzten Callbacks, auch bei Thin Clients, sehr wichtig.

[himitsu]

So im Großen und Ganzen isses schon nutzbar.

Bei den Verbindungsabbrüchen bin ich auch ins stocken geraten.
Theoretisch enthält DataSnap ein OnDisconnect, wo man notfalls versuchen könnte die Verbindung neu aufzubauen.
Nur ist es so, daß DataSnap manchmal garnicht mitbekommt, daß die Verbindung weg ist und dann dieses OnDisconnect nie aufruft ... gibt dann nur beim nächsten Versuch eine Servermethode aufzurufen eine schöne Exception. :wall:
Das liegt aber vermutlich eher am intern genutzen DBExpress, denn da kann man die DBConnection auch fragen, was man will, selber bei einem Verbindungsabbruch ist dessen Connected gerne mal True und auch regelmäßige .Connect aufzurufen bringt nichts, da DBX ja denkt es sei noch verbunden.
Am Ende zählen wir jetzt quasi die Verbindungsprobleme und führen dementsprechend abundzu mal ein Disconnect+Connect auf.

PS: Man kann DBX zwar ein Timeout mitgeben, aber wenn der Server mal Probleme hat, dann wird dieses ganz gekonnt ignoriert und auch der Client bleibt dann einfach hängen.
Unsere schnelle etwas unschöne Lösung > die Methodenaufrufe werden jeweils in einen Thread ausgelagert, welcher nach paar Sekunden einfach links liegen gelassen wird. :stupid:

[DSCHUCH]

paar dinge möchte ich hiermal dazu sagen:

1) es ist ein recht neues modul/produkt in delphi, dadurch gibt es natürlich einige probleme welche nicht sein müßten,

2) die paar probleme sind auf eine kurze liste zusammenzufassen, theoretisch könnte das in ein paar wochen behoben sein. wenn man denn nur will. ^^

dennoch:

3) es gibt nichts vergleichbares, mit dem man so schnell eine client-server sturktur aufbauen kann, welche auch noch flexibel und erweiterbar ist. die ganze protokollierung wird einem abgenommen. ich finde es super und denke wir hätten wesentlich länger gebraucht sowas selbst aufzubauen. wie gesagt - von der erweiterbarkeit mal komplett abgesehen.

4) mal schauen wie das von emba weiterentwickelt wird. ^^

daniel.

[mquadrat]

Könnte mir kurz jemand erklären wie sich Datasnap von WCF unterscheidet? Oder ist das Ziel eine WCF-entsprechende Foundation zu basteln?

[DSCHUCH]

nach 10 sekunden drüberfliegen würde ich sagen es ist das gleiche.

http://msdn.microsoft.com/en-us/library/ms731082.aspx

[Phoenix]

WCF ist eine reine Kommunikations-Schnittstelle. Eher vergleichbar mit einem aufgebohrten Indy oder RemObjects SDK.

DataSnap soll darüber hinaus auch noch Datenzugriff transparent ermöglichen. In etwa so, wie auch DataAbstract auf das RO SDK aufsetzt um die Datenzugriffe zu ermöglichen. Nur nicht so performant und ungeheuer umständlich. Auf .NET Ebene wäre das dann eine Kombination aus WCF und z.B. Entity Framework, zusammen mit noch ner Menge benötigtem Glue-Code die einem andere vollständige N-Tier Lösungen idealerweise abnehmen.

Will heissen: WCF & EF bietem einem (sehr gute) Tools um das alles selber zu machen. DataSnap versucht, einem hier noch ne Menge Arbeit abzunehmen, schafft das aber nur beschränkt und scheitert vor allem an Plattformübergreifenden Lösungen. DataAbstract schafft das sehr gut und ist dabei auch noch tatsächlich komplett Plattformübergreifend verfügbar.

[stahli]

Aber DataAbstract ist rein auf Datenbankanbindung ausgelegt - oder? Im Gegensatz dazu kann man mit DataSnap Objektdaten (beliebige Daten) über JSON zu speziell adressierten Clients übertragen. Ist das so richtig?

PS: Meine Kolleginnen diskutieren gerade über Aufklärung - das tut hier auch mal Not! :mrgreen:

[Phoenix]

Das geht mit DataAbstract bzw. konkreter mit dem enthaltenen und darunter liegenden RemObjects SDK auch. Es ist ein Remoting-Framework, das heisst Du kannst alles was Du magst über sämtliche Formate (Json, OData, Google Protocol Buffers, binär, optional auch verschlüsselt etc.) verschicken und empfangen. Die Feature-Liste ist glaube ich auch noch nicht ganz vollständig. ;-)

[mquadrat]

*tief in der Erinnerung wühl*

Da gab's doch was mit WCF Data Services.


Egal :-) Auf jeden Fall Danke für die Info.

[himitsu]

Ich hoffe ja mal Daniela schafft es doch zu den DT ... wäre gespannt, was sie so zu Unterrichten hat :)

Nja, Emba's Webinare und die Videos/Tutorials von Dr. Bob brachten am Ende auch keine goßen neuen Kenntnisse mehr, aber wenn man bei 0 anfängt, sind die genau das Richtige, wenn man mit DataSnap anfangen will.
Aber, wie gesagt, bitte nicht wundern, wenn ihr in den Beispielen vorallem bei Verwendung von Callbacks und bei allem mit JSON, Speicherlecks vorfindet, da oftmals vergessen wird die JSON-Objekte wieder freizugeben. :wall:



PS: Ich war bei meiner Recherche über DataSnap und seiner Ursprünge bis auf Delphi 5 runtergekommen, aber wie man mir sagte, fing es schon mindestens in Delphi 3 und Midas an. (neue Technik halt :stupid:)

[stahli]

Ich habe mal einige Videos zu DataSnap angesehen (und teilweise sogar etwas verstanden :wink:).
Um universelle Wege der Datenübvermittlung zu nutzen, scheint das ja ein ganz guter Weg zu sein.

Wenn ich aber eine Datenbankanwendung mit etwas anspruchsvollerer GUI (für komfortable Bedienung) für ein lokales Netzwerk erstellen will (mehrere Formular-Clients mit Zugriff auf eine Datenbank - keine geplante Internetanbindung o.ä.), bringt dann der Einsatz von DataSnap einen Vorteil?

Man hätte wohl eine gute Trennung von GUI/Logik/Daten, würde sich aber sicher auch einen Mehraufwand bei der Entwicklung einhandeln.
Macht das letztlich Sinn, wenn man eigentlich auch direkten Zugang zur Datenbank haben kann?

[Sir Rufo]

Ja, weil man diesen Zugriff auf die Daten von der DB unabhängig macht

[Furtbichler]

Midas läuft seit 12 Jahren in einem selbst entwickelten MES. Probleme gibt es keine, ich betreue das System immer noch.

[stahli]

@Sir Rufo

Kannst Du etwas konkreter werden?

Wenn die Option im Raum steht, das Projekt evtl. mal irgend wohin zu portieren oder einen Webbrowser-Client zusätzlich zu erstellen, dann kann ich das schon nachvollziehen.

Wenn das Projekt aber dauerhaft mit VCL-Forms und einem einmal festgelegten Dantanbankserver in einem Netzwerk laufen soll, dann reduziert sich der Nutzen doch schon wieder, oder?
Es bliebe also die Frage, ob ich eine "normale Netzwerkanwendung" effektiver erstellen und weiter entwickeln kann.

Die ganzen SQL-Statements etc. werden ja dann genau so benötigt, nur eben auf dem DataSnap-Server und nicht in den Clients...
(Ich muss mir dann (nach dem Fußball ;-)) mal noch ein paar Webinare anschauen)

[stahli]

MEissing´s Webinare sind schon interessant. Es geht aber dort nur so weit, dass existierende DB-Tabellen mal fix übertragen und angezeigt werden.
Wenn man einen Applicationserver einrichten kann, von dem man sowohl DB-Tabellen als auch irgendwelche Funktionsergebnisse abrufen (und natürlich Werte ändern) kann, klingt das schon reizvoll.
Die Clients müssen keine Daten und Logik mehr haben sondern sind lediglich für Darstellungen und Eingaben da.

Einige Fragen habe ich aber noch:

Wenn eine Tabelle mal 100.000 Datensätze hat und man diese an ein DBGrid bindet, puffert DataSnap dann automatisch die notwendigen zu übertragenden Daten oder werden alle 100.000 Datensätze an den Client übertragen?
Wie werden geänderte Datensätze an den Server zurück gesendet? Geht das automatisch oder muss der Client das explizit veranlassen?
Wie werden Konflikte verwaltet (ein Client will einen inzischen gelöschten oder geänderten Datensatz überschreiben). Es hat ja nur DataSnap Zugriff auf die DB (es gibt also wohl nur eine Transaktion)?

Ist eigentlich eine Art DataBinding von GUI-Controls an den DataSnap-Client möglich oder denkbar?
Ich meine das in der Form, dass man einem Edit eine Serverfunktion (z.b. die

Delphi-Quellcode:

function Person(ID: Integer): TPerson

) sowie eine ID zuweist und das Control sich bei Bedarf automatisch die benötigten Daten vom Server abruft bzw. Änderungen hin schickt.

[Sir Rufo]

Zitat:

Zitat von stahli (Beitrag 1135971)

Ist eigentlich eine Art DataBinding von GUI-Controls an den DataSnap-Client möglich oder denkbar?
Ich meine das in der Form, dass man einem Edit eine Serverfunktion (z.b. die

Delphi-Quellcode:

function Person(ID: Integer): TPerson

) sowie eine ID zuweist und das Control sich bei Bedarf automatisch die benötigten Daten vom Server abruft bzw. Änderungen hin schickt.

Um Himmels Willen bloß nicht ... Das edit Feld sollte solchen komplexen Operationen nicht vornehmen.
Schau dir dazu mal DSharp an, dann willst du sowas nie wieder versuchen ;)

[stahli]

Wie meinst Du das?

Wie eine Bindung an eine Objekteigenschaft funktioniert ist mir grundsätzlich schon klar. Bei einer Multi-Tier-Anwendung sehe ich aber das Problem, dass das zu nutzende Objekt auf dem Client möglicherweise noch gar nicht erzeugt worden ist bzw. dass die Daten erst von Server neu abgerufen werden müssen.
Daher denke ich, dass eine einfache Objektbindung nicht reicht.
Die Controls müsseten sozusagen direkt an den Proxyserver (bzw. eine bestimmte Funktion) gebunden werden.
Mir ist nicht klar, wie man den händischen Weg "aktuelle Serverdaten abrufen -> in das Edit schreiben -> Edit.Text an Server schicken" automatisieren kann.


PS: Falls jemand noch eine Antwort auf die anderen Fragen (größere Datenmengen / Änderungen rückschreiben / Konflikte) hat... das wäre noch nett.

[sh17]

Den grabe ich auch nochmal aus.

Wie ist der aktuelle Stand der Dinge bei DataSnap im Vergleich vielleicht zu RemObjectsSDK?

- Geschwindigkeit
- Stabilität

[jaenicke]

DataSnap ist nach wie vor relativ langsam. Unser größtes Problem ist aber die Verwendung von Blocking Sockets. Ansonsten gab es wenig Anlass zur Beschwerde.

Wir sind nun für einige Fälle auf ein Framework umgestiegen, das zwar deutlich weniger kann, aber schnell, einfach und nicht blockierend arbeitet, nämlich RTC. Das hat auch den Vorteil, dass es auch unter Android funktioniert, während das bei DataSnap nicht für alle Funktionen gilt.

Das Remobjects Remoting SDK kann zwar natürlich deutlich mehr, ist auch nach wie vor schneller als DataSnap und würde ich RTC und DataSnap vorziehen, aber da es genauso viel wie die Enterprise Edition von Delphi im Jahr kostet und wir die Funktionalität gar nicht ausnutzen würden...