Nein, in den ServerMethods steckt ja erstmal nur der Zugriffscode für die Clientenanfragen-
Von wo letztendlich die ausgelieferten Daten kommen, ist dabei erstmal egal.
Du mußt nur eventuell auf das Threading achen, also daß alles Threadsave ist,
Ich hatte damals den autogenerierten Servercode genommen, das selber in eigene Klassenstrukturen umkopiert und bissl angepasst. (genauso clientseitig)
z.B. Streams übertragen ist im DataSnap etwas heikel. (vorallem mit über 64 Kilobytechen)
* Es gibt im Server nur eine Instanz für alle (lifecycle = server)
* Bei Abfragen der Clienten wird das gewünschte DataSet aus einer globalen Liste gezogen, kurz gesperrt (Critical Section) kopiert und anschließend in Ruhe zum Clienten übertragen
* Dabei werden auch paar Problemfälle behandelt, wie z.B. daß es bei TEXT knallt (beim Kopieren wird einfach ein größeres VARCHAR daraus gemacht)
* bzw. seit heute wird in der Kopie auch noch eine Spalte clientspezifich angepasst (Werte geändert, bzw. eigentlich eine Art clientabhängiges CalcField angehängt)
Der Server wird als
DB-Cache benutzt, für längere
SQL, die häufig von Vielen abgerufen werden und praktisch fast überall das Selbe enthalten (bis auf ein paar Felder für die clientseitige Gridfilterung "ist meine", was bissl schwer zu lösen ging, da man GridFilter nicht speichern und vorallem synchronisieren kann, wenn darin "Zuständiger = HierMeinName" geprüft werden soll)
Und dann macht der DataSnap-Server noch paar weitere Dinge, wie ein eigener WebServer für die Hilfedateien (die Sicherheitsrichtlinien vom MS im Intranet sind echt besch***), Dateiserver für's DMS, EDI-Exporte, Backups usw.
Zitat:
verbraucht auch reichlich Connections
Und
RAM.