RemObjects Data Abstract, Schema Modeler erzeugt alles auf dem Client

[kretabiker]

Du kannst die notwendigen Komponenten (DataStreamer, Schema) selbst auf dem Servicecontainer platzieren und dann die Properties entsprechend den vom Wizard erzeugten Komponenten setzen.

Ich verwende für jeden Service ein eigenes Schema, aus rein organisatorischen Gründen. Bei Datenbanken mit vielen Tabellen geht sonst im Schemamanager leicht die Übersicht verloren. Ich habe daher meine Services funktionsbereichsorientiert strukturiert.

Ob du für eine Tabelle mehrere DataTables im Schema anlegst, ist Geschmackssache. Es ist grundsätzlich möglich, mit einer DataTable zu arbeiten und dann per Dynamic Select die Spalten einzugrenzen - siehe Wiki. Lesenswert dazu sind auch die Ausführungen zur Klasse TableRequestInfoV5, ebenfalls im Wiki. Caveat: Ziemlich viel Tipperei. Und bei nicht-AutoSQL-Datatables werden trotzdem alle im Select-Statement enthalten Felder gefetcht und erst bei der Übermittlung zum Client die nicht angeforderten Felder entfernt - bei AutoSQL dagegen werden tatsächlich nur die angegebenen Felder beim Datenbankserver abgefragt.

Mit den Metadaten hatte ich auch bei eigenen Selects keine Probleme, ich muss nur manchmal auf Recreate bei den Feldern und Parametern des DataTables klicken. Im Client-MemDataTable muss ich die Tabellenstruktur nach jeder Änderung im Schema neu abfragen, da findet kein automatisches Sync statt. Bei den Feldern habe ich mir angewöhnt, die erzeugten Einträge zu prüfen, insbesondere bei Blobs mit SubType 1 für Text (in Firebird) kommt es hier gelegentlich zu Problemen. Und für Felder des Primary Keys, für die es in Firebird keine echten AutoIncs gibt, muss der Generator (falls verwendet) von Hand gesetzt werden.