![]() |
Tabelle in Event updaten
Tach Zãmma,
habe gerade ein Problem, das ich hier nicht recht einzuordnen weiß, sage daher einfach mal, dass es sich um ein Algo/Design Problem handelt. Jetzt mal die Aufgabenbeschreibung: Wir haben ein Table mit verkürzten Datensatz und Grid. Im Grid selbst soll ein einer Relation nur ein Tupel einen bestimmten Wert erhalten (beispielsweise Radio Button über alle Tupel). Hierzu wird im Grid was passendes realisiert, beim speichern soll dann nachgesehen werden ob ein anderes Tupel der Relation den Wert bereits besitzt und dieser dann ggf zurückgesetzt werden. Hierzu würde ein before-/after Post Ereignis implementiert. Jetzt kommt das Problem, wenn hier eine Rücksendung erfolgt, springt es in der gleichen Tabelle wieder zurück in das Ereignis ohne dass das Ereignis fertig abgearbeitet wird. Kurzum, die Komponente ist nicht rekursiv fähig! Hat jemand schon mal so etwas realisiert und hat hier einen Tipp, wie man das abbilden kann? Vielen Dank dsp |
AW: Tabelle in Event updaten
Ich verstehe leider nur Bahnhof ... :cry:
|
AW: Tabelle in Event updaten
Ist eigentlich ganz einfach :)
Man nehme eine TTable -> T Implementiere ein Event: AfterPost Dann wird der Tupel (Datensatz, d) {key: 1, Wert: false} auf {1; true} geändert. Der d{2; true} verletzt die Restriktionen und ist daher auf {2; false} anzupassen. Daher irdischen sich im Post gemerkt, ist der aktuelle Datensatz angepasst worden, dann gehe durch die anderen Datensätze und passe die ebenfalls an. Das geschieht im AfterPost von T. Beim Post von T{2; false} wird dann wieder T>AfterPost aufgerufen.... Und die Komponente bekommt einen Knoten :( Vielleicht ist das Problem nun etwas klarer. Grüße dsp |
AW: Tabelle in Event updaten
Alter...das muss ich 3-4 mal lesen, damit ich es auch nur 1 mal evtl. verstehe.
Zitat:
Nimm doch mal was nachvollziehbares, und vielleicht ein wenig Codeschnipsel. |
AW: Tabelle in Event updaten
Dann hinterlege die Restriktionen (Constraints) im DBMS. Oder verwende BeforePost, dann kannst Du diese noch anpassen oder den zumindest den Post verhindern.
|
AW: Tabelle in Event updaten
Also ich glaube jetzt soweit verstanden zu haben, daß im AfterPost ständig wieder AfterPost ausgelöst wird, was eine Endlosschleife wäre ("die Komponente bekommt einen Knoten").
|
AW: Tabelle in Event updaten
Ich musste die Angabe auch ein paarmal lesen.
Warum setzt Du in der AfterPost()-Methode kein Semaphore, welches Dir anzeigt, dass Du dich gerade in der Bearbeitung der Daten befindest und welches verhindert, dass AfterPost() ein zweitesmal durchlaufen wird? Wenn Du das nicht machst, dann wird AfterPost() natürlich immer wieder aufgerufen. Nachdem Du die Daten bearbeitet/manipuliert hast, wird das Semaphore einfach wieder zurückgesetzt und die Methode wieder "scharf" gesetzt für das nächste Event. |
AW: Tabelle in Event updaten
![]() |
AW: Tabelle in Event updaten
Ja, sowas wie ein Flag meinte ich.
Die Variable könnte dann innerhalb der Klasse definiert sein (und kann dort natürlich auch private sein). Global hört sich so schlimm an :wink:! |
AW: Tabelle in Event updaten
Wußtest du schon? Variablen können sogar global und privat sein: Im Private-Abschnitt deklariert, aber für die ganze Klasse global gültig. Und das was du meintest, ist nicht nur sowas wie ein Flag, es ist ein Flag,
![]() Ein ![]() Ein Semaphor (von altgriechisch σῆμα sēma „Zeichen“ und φέρειν pherein „tragen“ - also etwa „Signalgeber“) ist eine Datenstruktur, die aus einer Ganzzahl und den Nutzungsoperationen „Reservieren/Probieren“ und „Freigeben“ besteht. Sie eignet sich insbesondere zur Verwaltung beschränkter (zählbarer) Ressourcen, auf die mehrere Prozesse oder Threads zugreifen sollen, wie etwa Erzeuger und Verbraucher, sowie zur Koordination asynchroner Abläufe. Im Gegensatz zu einem Lock bzw. einem Mutex brauchen die Aktivitätsträger, die „reservieren“ und „freigeben“, nicht identisch zu sein. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:48 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz