Danke...
Zitat:
gestalte das ganze doch noch etwas abstrakter: Warum bittest du nicht einen "
DB-Manager" um eine
Query und arbeitest dann mit dieser?! Beim Start der Anwendung musst du dem
DB-Manager lediglich einmal die Connection-Informationen übergeben und gut ist das.
Zitat:
In dieser GetQuery()-Methode wird dann automatisch geprüft, welcher Thread aufgerufen wird. Ist für den Thread noch keine Verbindung aktiv, so wird eine neue aufgebaut und die
Query in diesem Kontext erzeugt.
...ich weis zwar wie du das meinst, kann das aber praktisch nicht umsetzen. Könntest du das etwas genauer erklären ? Vieleicht mit einem Schema (vereinfacht) des Quelltextes ? So nach dem Motto wer ruft von wo was auf, wer erzeugt was ?
Derzeitiger Stand:
1.
DB Framework (eine Klasse, vorbereitet um mal ein Interface draus zu machen (Getter/Setter) )
1.1 von außen kann ich ggf. eine Transaktion öffnen wenn benötigt. Intern haben die zusammengehörigen
SQL eine Transaktion für sich
- Save... procedure Save(aPlantScheme: TeAV_PlantScheme)
- anhand der Property PlantScheme.State wird unterschieden ob Insert/Update/Delete
in update Prozedure:
- Query1. Execute (Transaktion der Connection)
- Thread erzeugen
- im Thread Query2 und
Query 3 (seperate Connection, eigene Transaktion)
wenn ich mir vom
DB Framework eine
Query hole (vom Thread aus ?) kann der ganze Kram trotzdem erst gemeinsam Commited werden. (evt. zu lange)
Zitat:
Dann packe das ganze doch in einen einzigen Thread und Transaktion und gut ist.
PS: ich habe die Geschwindigkeit nicht gemessen. Normalerweise geht das schnell. Über den Tellerrand blickend wäre die Konstellation, Laden erfolgt vor dem Commit, durchaus möglich.