Autor Thema: Geht PostSave oder was ähnliches auch mit im BE gespeicherten Document?  (Gelesen 2169 mal)

Offline Sascha Seipp

  • Aktives Mitglied
  • ***
  • Beiträge: 139
  • Geschlecht: Männlich
Moin allerseits!

Hab ein wenig die Suche bemüht, aber so direkt nix gefunden - mag aber auch daran liegen, daß ich schon ebbes müde bin..

Folgendes Problem: Ein Dokument (A) soll nach seiner Speicherung per PostSave in einem anderen Dokument (B) noch ein paar Werte setzen. Solange A im FE bearbeitet und gespeichert wird, seh ich da auch kein Problem (hab zum Testen ins PostSave erstmal einfach ne MsgBox gesetzt).
Wenn das Dokument A aber im BE erzeugt und gespeichert wird, scheint das PostSave nicht zu laufen.

Ist das so? Kann man da was anderes nehmen? Oder wo denke ich falsch?

Ich danke schonmal für Erleuchtung!

Ciao
Sascha

Offline ZaLudtske

  • Senior Mitglied
  • ****
  • Beiträge: 319
  • Geschlecht: Männlich
  • carpe diem
Hallo,

die Ereignisse werden meines wissens nur im Frontend ausgelöst. Wenn du im Backend das Dokument erzeugts, dann mußt du auch im Backend das andere Dokument bearbeiten.

Rainer
Rainer Zaske

MCSD - C#

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Rainer hat vollkommen Recht: PostSave und weitere Maskenevents greifen immer nur im Frontend, ebenso, wie die Maske ja ein reines Frontend-Element ist, was im Backend überhaupt nicht gebraucht wird.

Bernhard

Offline Sascha Seipp

  • Aktives Mitglied
  • ***
  • Beiträge: 139
  • Geschlecht: Männlich
Dankeschön!

Dann werde ich meine ToDo's in eine Funktion packen, die ich gleichermaßen aus PostSave wie auch in der Backend-Geschichte aufrufen werde. Dann sollte das passen.

Ciao
Sascha

Offline pete_bla

  • Senior Mitglied
  • ****
  • Beiträge: 455
  • Geschlecht: Männlich
  • dot net gitz net!
Hi,

Was du verwenden willst wäre dann die klassische Möglichkeit.

Andererseits würde ich Dir dazu raten, vor allem wenn Du Dokument-A nach B und B nach A ändern willst,
dass Du dir nochmals genau überlegst, ob das notwendig ist!

Persönlich meide ich "beim Speichern des einen Dokument ein anderes zu ändern"
wie der Teufel das Weihwasser! 
Dies ist wunderbar für Speicher und Replizierkonflikte!  >:D

Darum die Frage:
Sind die Daten die vom A nach B müssen, und umgekehrt wirklich in Ansichten relevant
oder nur in der Anzeige des Dokuments?

Wenn nein, dann verwende lieber Felder "Berechnet zur Anzeige" oder irgendwelche "QueryOpen" Aktionen um die Infos zu holen.

Grüsse und viel Erfolg, Pete(r)
pete(r)

Offline Sascha Seipp

  • Aktives Mitglied
  • ***
  • Beiträge: 139
  • Geschlecht: Männlich
Hallo Pete(r)! [wie denn nu? :-)]

Mal konkret angerissen, worum's geht:
Eine Inventarisierungsdatenbank für IT-Equipment.

Mein Dokument B wäre ein Inventar-Teil, z.B. der Monitor mit der Seriennummer 4711.
Das Dokument A ist eine mit dem Inventar-Teil ausgeführte Aktion, z.B. Einlagerung als Neuware, dann wäre im Dokument B das Flag 'Bestand' auf 'ja' zu setzen. Wenn ich dann ein anderes Dokument A habe, nämlich ne Neuartikel-Ausgabe, würde diese das Flag 'Bestand' wieder auf 'nein' setzen.
Andererseits geht die PickList, mit der ich in so einer Neuartikel-Ausgabe das auszugebende Teil auswählen kann auf eine Ansicht, in der nur Inventar-Teile mit Bestand = 'ja' angezeigt werden.
Ein anderes Flag wäre 'Status', wo dann drinsteht "Beim User", "Im Lager", "In Reklamation" oder so, sodaß ich bei den jeweiligen Inventar-Bewegungen in der Auswahl nicht alle vorhandenen Teile drinstehen habe, sondern nur die, die tatsächlich in Frage kommen.

Prinzipiell hatte ich ja anfangs sowas überlegt wie "aus der letzten Inventar-Bewegung des Teils den aktuellen Status ableiten", aber das erscheint mir für eine Ansicht deutlich schwerer umzusetzen, wenn nicht gar unmöglich (zumindest aber aufwendig).
Das wäre dann sowas wie eine Ansicht, deren Dokumente so definiert sind, daß sie in einer anderen umgekehrt nach Datum sortierten Ansicht jeweils die ersten pro Kategorie sind, wobei die Inventar-Nummer dann die Kategorie wäre oder so. Klingt eher grausam, glaub ich.

Daß das am liebsten atomar (was natürlich nicht klappt) ausgeführte Speichern von zwei Dokumenten nacheinander zu Problemen führen kann, kann ich mir schon vorstellen, denke aber mal, für diese Anwendung (mit nur ca. 6 bis 8 Usern) sollte das in den Griff zu kriegen sein.

Für andere Ideen / Ansätze bin ich aber gerne offen.

Ciao
Sascha

Offline pete_bla

  • Senior Mitglied
  • ****
  • Beiträge: 455
  • Geschlecht: Männlich
  • dot net gitz net!
Hi Sascha,

denke aber mal, für diese Anwendung (mit nur ca. 6 bis 8 Usern) sollte das in den Griff zu kriegen sein.
bei der Useranzahl ist auch ein "Konflik" leicht manuell handelbar und ein anderes Konzpt könnte wie Du sagst etwas komplexer zu basteln sein.

Ich gehe auch nicht davon aus, dass du die DB clusterts, auf mehreren Servern um die Welt schicksts oder etliche lokalen Repliken verteilt sind.  ;)

Wollte nur mal etwas den Reichsbedenkenträger  rauslassen,
da ich mit solchen Hinundherscheibereien (sogar im QueryOpen und QueryClose  >:D auf andere Dokumente!) so manches Schräge gesehen habe und die Verursacher haben sich "davon gemacht" (bzw. wurden - zurecht!).

Grüsse, Pete(r)

PS: schreib pete_bla, Pete oder Peter.
(Die Kollegen im Forum wollten nur mal, dass ich zumindest meinen vollen Vornamen angebe.)
pete(r)

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz