Moin, ist jemandem etwas aufgefallen, ob bei DataSnap mehr Daten ankommen, als man weg schickt?

Problem:
Bei uns kommen alle Text-Felder bis zu 4 Mal so groß beim Clienten an, als sie der Server bekommt.
xxx im Server-Query wird zu xxx im Client-Query
* VARCHAR(1) -> TWideStringField(10)
* VARCHAR(30) -> TWideStringField(126)
* VARCHAR(100) -> TWideStringField(402)

Da wir damals Probleme mit MEMOS/BLOBS hatten, wo sich DataSnap weigerte die übertragen zu wollen, hatten wir TDBXDataSetReader.CopyReaderToDataSet kopiert und etwas abgeändert.
Dort wird aus TEXT (TDBXDataTypes.BlobType+TDBXSubDataTypes.MemoSubTy pe) ein TDBXDataTypes.WideStringType mit Länge 5000 gemacht, aber sonst ist alles gleich.
Bei dem WideStringType(5000) wird die Länge aber nur verdoppelt und nicht vervierfacht
* VARCHAR(5000) -> TWideStringField(10002)

Also scheinbar wird einmal vor und nach TDBXDataSetReader.CopyReaderToDataSet jeweils verdoppelt.
Ob das Nachher serverseitig oder clientseitig passiert, weiß ich noch nicht.

Serverseitig gibt es eine Reihe gecashte DataSets, die bei Abfrage kopiert werden und die Kopie wird dann von DataSnap mittels TDBXDataSetReader übertragen und freigegeben.
Der Apps hat quasi so eine Methode function GetDataSet(QueryName: String): TDBXDataSetReader; und im Client wird dann wieder mit TDBXDataSetReader.CopyReaderToDataSet der Inhalt in ein TClientDataSet kopiert.
Zusätzlich werden dabei noch clientabhängig serverseitig sowas wie CalcFields angehängt und gefüllt, bzw. Datensätze rausgefiltert (nicht mit kopiert), beim Umkopieren innhalb von CopyReaderToDataSet.
Das hat aber alles keinen Einfluss auf die meisten VARCHAR-Felder, welche sich dennoch einfach so vergrößern.



Das Problem ist jedenfalls, daß wir nun im Client ein Dataset haben, das bei einem Kunden teilweise 500 MB belegt und es dann beim Scannen knallt, wenn auch noch ein größeres Bild in den RAM rein möchte.
In meinem Test sind das z.B. 3 TEXT, welche bei 2000 Datensätze über 120 MB RAM verschwenden. 10000*2 * 3 * 2000 = 120.000.000 , zuzüglich der anderen Spalten im SQL, wo die VARCHAR auch 4 Mal so groß sind.


Ist das ein allgemeines Problem, welches eventuell schon bekannt ist?
Bevor ich hier weiter viele Stunden in DataSnap versenke und versuche das zu finden.

Mal eine Vermutung (keinerlei fundierte Sachkenntnis):

Die erste Verdoppelung wegen UTF16
Die zweite Verdoppelung wegen CurValue/OldValue
http://docwiki.embarcadero.com/Libra...Field.CurValue
http://docwiki.embarcadero.com/Libra...Field.OldValue

Da das eine Feld schon ein WideString ist (UTF16) braucht es die erste Verdoppelung nicht mehr

Nein, das hat damit nichts zu tun.
> TField.DataSize und TField.Size
Dass da intern nochmal mehr Bytes sind, ist auch klar, aber hier geht es quasi nur um "CurValue".
Außerdem gibt es OldValue doch standardmäßig nur für den aktiven Datensatz und nicht für alle Datensätze.

Ja, DataSize ist größer, wegen Unicode.
Wie groß das Feld in der Datenbank ist, ist mir egal (ist da UTF-8 und das sind 4 Byte pro Char, im Postgres), da es im DataSet dann als Unicode steht.

Aber im TPgQuery/TClientDataSet ist, vor dem DataSnap/TDBXDataSetReader, die TWideStringField.Size z.B. 100 "Chars", bzw. TWideStringField.DataSize 202 Bytes (inkl. Längen-Word)
und nachher ist im TClientDataSet des Clienten die TWideStringField.Size 402 "Chars", bzw. TWideStringField.DataSize 802 Bytes (inkl. Längen-Word).
Bei den 10000 Chars ist es dann ein Längen-LongWord im DataSize.

http://docwiki.embarcadero.com/Libra...ideStringField
http://docwiki.embarcadero.com/Libra...DB.TField.Size > ftString = Size gibt die maximale Anzahl der Zeichen im String an.

Was steht den drin?
Wenn Du statt x31x31 dann x00000031x00000031 bekommst, dann spricht dich viel für Sir Rufo's These. Bei einen x31x31x00x00x00x00 handelt es sich wohl eher um ein nicht sehr sinnvolles hinten anpappen. (Kopie mit fixen Werten statt charsize)

Gruß
K-H

SELECT 'abc'::VARCHAR(10)

im PgQuery - NativeFormat ist kaputt, oder warum bekomm ich die LängenBytes beim PgQuery nicht mit raus?
10:22=61006200630000000000000000000000000000000000
10:22=61006200630000000000000000000000000000000000

im ClientDataSet nach DataSnap
46:94=060061006200630000200000005C0B0F000100000210D718008508190694D71800 6002CE0DAA382850B0A9FA7630F7AE00780000008508190685 0819066002CE0D94D718006FDF275085081906200000006002 CE0DF0EDA476A255F7FAFE
46:94=61006200630000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000

zusammenfalten · markieren

Delphi-Quellcode:

SetLength(B, DS.DataSet.Fields[0].DataSize);
SetLength(S, DS.DataSet.Fields[0].DataSize * 2);
DS.DataSet.Fields[0].GetData(@B[0], True);
BinToHex(B[0], PChar(S), DS.DataSet.Fields[0].DataSize);
ShowMessage(IntToStr(DS.DataSet.Fields[0].Size) + ':' + IntToStr(DS.DataSet.Fields[0].DataSize) + '=' + S);

B := nil;
SetLength(B, DS.DataSet.Fields[0].DataSize);
SetLength(S, DS.DataSet.Fields[0].DataSize * 2);
DS.DataSet.Fields[0].GetData(@B[0], False);
BinToHex(B[0], PChar(S), DS.DataSet.Fields[0].DataSize);
ShowMessage(IntToStr(DS.DataSet.Fields[0].Size) + ':' + IntToStr(DS.DataSet.Fields[0].DataSize) + '=' + S);

Aber, wie gesagt, SIZE gibt die "Zeichen" an, also sollte das unabhängig davon sein, wie das intern gespeichert wird.
3 UTF-8-Zeichen bleiben doch 3 Unicode-Zeichen


[edit] vielleicht speichert TPgQuery das einfach 0-terminiert und TClientDataSet mit Längenangabe.