Fakturierungsserver

[Jumpy]

Zitat von psycodad:

Ich könnte jetzt jeden dieser Prozesse in einen TTask legen und schon ginge das besser.

Das wäre das erste, was ich auf jeden Fall machen würde. Entwickelt eine saubere entkoppelte Programm-Logik, die eure Dinge fakturiert. Multitheraded mit Pools und Queues usw., die ggf. mehrere Dinge gleichzeitig fakturieren kann. Optimiert es soweit es geht.

Dann kann man überlegen, dass im Desktop-System einzubauen. Ist wahrscheinlich dann immer noch nicht optimal, weil es Resourcen an der falschen Stelle frisst. Oder aber man baut losgelöst ein Server-Programm in dem man seine Fakturierungs-Logik unterbringt. Dann muss man sich "nur" im Desktop-Programm um eine Kommunikation mit dem Server kümmern und da ist es dann sowohl denkbar, dass Client und Server direkt miteinander kommunizieren oder aber das sie über die Datenbank "kommunizieren", indem der Client ein Ding zur fakturierung frei gibt, der Server nach solchen Dingen sucht und dies dann einem Thread zur bearbeitung übergibt.

Was ich eigentlich sagen will: Betrachtet das als zwei Dinge: Optimierung der Fakturierungs-Logik und Client-Server-Geschichte.
Für letzteres findest du dann vielleicht eher Vorlagen oder Pattern, bei ersterem kann euch eh kein Fremder wirklich helfen.

[jobo]

Wenn man
die SP auf dem SQL Server variiert und
über DB Jobs und Schedules anspricht und
den Delphi Client nur noch zum Einlagern in die Jobqueue
und zur Visualisierung von (Zwischen)Ergebnissen nimmt, braucht man nicht mal threads in Delphi.

Wenn man natürlich in Delphi viel Rechnungslauf Know How implementiert hat und erhalten möchte, dann ist es wahrscheinlich sinnvoller, es dort zu behalten und optimiert zu nutzen.