so basically i’m also trying to get the serialize to be faster…
You mean the one where statement name field was not present in the new Schema Modeler? This issue has been fixed some time ago.
Hi,
bin2+mem will show better performance in comparing with bin1+cds
as I can see, bin2 uses GetNativeFieldData near to GetNativeFieldValue so it receives native data instead of variant…
sdac does not have getnativefielddata? or did i miss something?
i stand corrected!
have to see what that gives
thx!
Hi,
it was implemented in TDANativeDatabaseAccess_Dataset.GetNativeFieldData
i beg to differ…
procedure TDABin2DataStreamer.InternalDoWriteDataset_NonDataset_without_events
will call
InternalDoWriteDataset(Source, k, Maxrecords, ARealFields, aDataIndex, info);
which calls
procedure TDABin2DataStreamer.InternalDoWriteDataset_without_events(
const Source: IDADataset; var k: integer; const Maxrecords: integer;
ARealFields: array of integer; aDataIndex: Integer;
info: array of TDASmallFieldInfo);
to serialize the dataset
the if does not apply
if not ev and b and Supports(Source,IDAMemDatasetBatchAdding) then begin
// memdataset special mode
in
procedure TDABin2DataStreamer.InternalDoWriteDataset_NonDataset_without_events
which i assume does the streaming differently
so how is the native field accessed when writing datasets on the server side using SDAC driver?
Hi,
even if it uses InternalDoWriteDataset_without_events, it doesn’t convert all values to variant as you wrote:
...
datLargeUInt: Bin2_WriteUint64ToStream(Data, flds[i].AsLargeUInt);
datByte: Bin2_WriteByteToStream(Data, flds[i].AsByte);
datShortInt: Bin2_WriteShortIntToStream(Data, flds[i].AsShortInt);
datWord: Bin2_WriteWordToStream(Data, flds[i].AsWord);
sorry i was looking at the dabinstreamer code instead of dabin2
so doing some other timings i found that the majority of the time goes to source.next
so traversing to the next record in the daesdacquery …
of the 900 msecs needed 700 msecs goes to source.next
so i’m wondering if for example unidac would be faster then sdac (although both from the same company) or that anything else could speed up the .next operation…
Hi,
you may play with some options of SDAC via options.XXX=YYY.
see about this at https://www.devart.com/sdac/docs/devart.sdac.tmsconnection.options.htm
UniDAC allows to set more options for SQL server: https://www.devart.com/unidac/docs/using-sqlserver.htm so it can be more flexible.
looking at the sdac code it seems that
TMSQuery(result).FetchAll := True; //for preventing creating an additional session when you call StartTransaction (an known issue of OLEDB)
TMSQuery(result).Unidirectional := True;
are mutually exclusive…
not sure what effect Fetchall= false has…
our license of SDAC doesn’t contain sources 
so I can’t say how it is implemented in their code…
function TDAESDACQuery.CreateDataset(aConnection: TDAEConnection): TDataset;
begin
result := TMSQuery.Create(nil);
TMSQuery(result).FetchAll := True; //for preventing creating an additional session when you call StartTransaction (an known issue of OLEDB)
// TMSQuery(result).Unidirectional := True;
if i comment out the unidirectional setting then the total of 900 msec drops to 200 msec and the .Next operation drops from 700 msec to 12 msec
the only i don’t know if the 700 msecs aren’t consumed at fetching in Sdac now…
total timing in gui stays the same…
i’ll pick it up with devart