Ich weiß nicht, ob das komponentenspezifisch ist, aber gefühlt gibt es in der Kommunikation viel Overhead/Kleinkram, sagen wir mal, das läuft recht geschwätzig und das tut dann spätestens im WLAN weh, Unidac habe ich aber noch nie benutzt.
Multithreading macht das nicht unbedingt besser, weil gleiche Zugriffs-Technik, es läuft nur asynchron.
Ich würde daher vielleicht versuchen, die einzelnen Queries mit mehr Daten zu beladen, bei einem
Query gleicher Overhead, aber mehr "Nutzlast". Dafür müsste man allerdings auf Parametrierung verzichten. Soweit ich weiß kann
SQL Server anonyme Blöcke. Das ergäbe soetwas in der Art in einer
Query:
Code:
begin
insert into mytable [feldliste*] values (werteliste);
insert into mytable [feldliste*] values (werteliste);
insert into mytable [feldliste*] values (werteliste);
..
end
oder sogar- glaub
sql server kann das
Code:
begin
insert into mytable [feldliste*] values ((werteliste);
(werteliste);
(werteliste));
..
end
* feldliste kann man aus Platzgründen vlt auch weglassen, wenn vollständige Werteliste da ist und sichergestellt, dass es zusammenpasst.
Ich könnte mir vorstellen, dass einzelne Queries mit 5, 10 -50 Sätzen ähnlich schnell verarbeitet werden, wie ein einzelner Satz jetzt bei Dir.
Serverseitig könnte man ggF. noch prüfen, ob die Tabellenstruktur für schnelle inserts geeignet ist (wenig/kein Index, ..)