möglichst kurze Transaktionen

[kiar]

hallo hansa

folgender lösungsvorschlag:
start transaction lesen aller notwendigen daten commit

in deinem clienten alle eingaben machen
start transaction update aller notwendigen daten commit

[Hansa]

Ich kann doch nicht 20.000 Datensätze lesen, wenn ich nur 5 tatsächlich brauche. Angeblich geht das parallel. Bei der lesenden kann ich ruhig mal Kaffee trinken gehen, die schreibende wird auf einen Schlag ausgeführt. Deshalb die Frage, macht das jemand so in der Richtung

[kiar]

mit sfw block brauchst du ja nur die datensätze zu holen die du brauchst.ich kann deinen einwand nicht verstehen. wenn du 5 datensätze brauchst holst du nur 5

[Hansa]

Ich brauche einen, dann vielleicht noch einen. Ist alles erfaßt, dann speichere ich alles ab. Vielleicht werden es aber doch 100, und ich bin eine Stunde am Erfassen, wer weiß Die Transaktion wäre dann auch solange aktiv. Wie soll ich das verkürzen? Wie macht ihr so was denn ?

[kiar]

hallo hansa an bei ein tut über sql.

dies solltest du durcharbeiten, denn was du mit deinem programm machen willst ist von aussen schlecht einzusehen. ich denke dieser link
http://www.w3schools.com/sql/default.asp sollte dir helfen.

viel spass bei sql

[urs.liska]

Mein Vorschlag zu einem Transaktionsmodell wäre:
Jedesmal, wenn Du einen Artikel in die Rechnung einfügst, brauchst Du eine kurze Transaktion, die eben diesen Artikel einliest, die dann aber auch wieder beendet werden kann.
Und am Schluss nochmal eine kurze Transaktion zum Schreiben.
Natürlich musst Du damit rechnen, dass in der Zwischenzeit jemand anderes den Lagerbestand geändert hat, d.h. Du musst beim Schreiben diese Möglichkeit mit einbeziehen und evtl. darauf reagieren. Aber bei einer langen Transaktion gibt es dieses Risiko natürlich auch, daher ist es kein Argument gegen das von mir vorgeschlagene Modell. Und ich denke, das ist der "übliche" Weg, ganz unabhängig von den verwendeten Komponenten.

Grüße
Urs

[harrybo]

Hi Hansa,

um Deine Frage zu beantworten "macht das jemand so in der Richtung?": ich mache das so, bei einem etwas zurückliegenden Projekt sogar ausschließlich. Auf Transaktionen muss ich ja hier nicht mehr eingehen, die wurden ausführlich behandelt. Allerdings nur schnell mal commiten reicht bei Interbase/Firebird auch nicht ganz, wenn Du mit datensensitiven Kompos wie DBGrid o.ä. arbeitest - die sind dann nämlich augenblicklich leergefegt, da Commit sämtliche über die Transaktion laufenden Datasets etc. schließt. Man müsste also sämtliche offen gewesenen Datenmenge neu öffnen (in Mehrbenutzerumgebungen teilweise kein Manko, da erwünscht).

Meine Lösung war tatsächlich der Einsatz zweier Transaktionen mit folgenden Aufgaben:

• Transaktion 1 zum Lesen, solange ein Fenster, bzw. die Datensicht offen ist. Das automatische Schreiben der benutzten datensensitiven Komponenten wird abgefangen und unterbunden, stattdessen wird ein SQL String erzeugt und an die
  Transaktion 2 zum Schreiben (Insert, Update) geschickt.

Großer Vorteil hierbei: Das Schreiben lasse ich eben nicht DBGrid, bzw. DBEdit machen, sondern verwende ausschließlich SQL über die entsprechende Komponente, die über Transaktion 2 läuft, was schneller nicht geht. Diese Transaktion "lebt" tatsächlich nur für die Dauer des Schreibens. Nach dem Schreiben lese ich die über Transaktion 1 offenen Datasets neu ein, damit die Änderungen auch sichtbar werden. Vor diesem Requery werden sämtliche Datenanzeigen mit Dataset.DisableControls eingefroren, um Flickern zu verhindern, abschließend werden die Anzeigen mit Dataset.EnableControls wieder freigegeben.

Gruß harrybo