Autor Thema: @DbLookup findet erst nach mehrmaligem "Designrferesh" Werte  (Gelesen 1727 mal)

Offline Obrac

  • Senior Mitglied
  • ****
  • Beiträge: 277
  • Geschlecht: Männlich
Hallo zusammen,

da ich in der Causa mit meinem Latein am Ende bin, versuche ich es mal hier: Ich habe ein Feld in einer Maske, das sich per @dblookup Werte aus einer Ansicht holen soll. Die erste Ansichtsspalte enthält eine Nummer, der Schlüssel in der Feldformel ist auch eine Nummer (habe schon versucht, beides in Text zu konvertieren, hat nichts geändert). Wenn ein neues Dokument angelegt und die Nummer dort eingetragen und das Doc gespeichert wird, gibt es erst einmal die Meldung "Serverfehler: Eintrag im Index nicht gefunden". Erst wenn ich @Command([ToolsRefreshSelectedDocs]) drüberlaufen lasse, erscheint der korrekte Feldwert. Normalerweise sollte er sich aber doch selbst aktualisieren ("Feldwerte automatisch aktualisieren" ist in den Maskeneigenschaften aktiviert). Was mich stutzig macht, ist, dass in der Maske andere Felder auch per @DBLookup aus anderen Ansichten Werte holen, was auch einwandfrei ohne explizierte Aktualisierung klappt.
Evtl. noch wichtig: Das Dokument findet per @DbLookup u.a. auch sich selbst, aber auch andere Docs mit derselben Nummer und gibt die Werte dann per Textliste aus. Grundsätzlich funktioniert das auch, aber nur durch den @Command. In einer anderen Maske wird genau das gleiche gemacht, und da klappt es ohne Refresh. In dem Moment, in dem das Doc gespeichert wird, landet es ja in der Ansicht. Was könnte der Grund sein, dass es nicht ad hoc klappt?

Offline Flachmann

  • Senior Mitglied
  • ****
  • Beiträge: 284
  • Geschlecht: Männlich
  • Mal wieder: Flachmann ist Schuld!
Evtl. ein Caching-Problem? Hast Du den @DbLookup mit dem [NoCache]-Parameter ausgeführt?
Gruß,
  __________
  _/_
  /lachmann

Offline Tode

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 6.883
  • Geschlecht: Männlich
  • Geht nicht, gibt's (fast) nicht... *g*
Das sieht mir schwer nach einem Verständnisproblem aus:

Ein Dokument kann erst in der Ansicht gefunden werden, nachdem es mindestens einmal gespeichert wurde. Wenn Du also ein @DBLookup auf das Dokument selbst machst, dann wird das immer den Fehler "Eintrag im Index nicht gefunden" kriegen. Die Frage ist: Warum willst Du überhaupt ein Feld im Dokument über einen Lookup auf das selbe Dokument befüllen?

Nehmen wir mal ein Beispiel: Ich habe eine Maske mit 3 Feldern:

Category: Textfeld
Subject: TextFeld
AllSubjectsForCategory: Textfeld, mehrfachwerte, berechnet.

Im Feld AllSubjectsForCategory steht die Formel:

Code
@DBLookup( "" : NoCache" ; ""; "LookupCategories" ; Category; "Subject" )

Jetzt erstellst Du ein Dokument:
Category: Erste Kategorie
Subject: Mein Thema

Wenn ein Dokument das erste in seiner Kategorie ist, dann wird im Feld AllSubjectsForCategory stehen: Eintrag im Index nicht gefunden.. Wenn Du dann nochmal speicherst, dann steht da "Mein Thema".
Wenn Du ein zweites Dokument erstellst mit diesen Werten:

Category: Erste Kategorie
Subject: Anderes Thema

dann steht beim ersten speichern im Feld AllSubjectsForCategory:
Mein Thema

beim zweiten speichern steht dann drin:
Mein Thema
Anderes Thema

Wenn Du schon beim ersten speichern beide Werte haben willst, dann musst Du einfach die Formel erweitern:

Code
_lkp := @DBLookup( "" : NoCache" ; ""; "LookupCategories" ; Category; "Subject" );
@Trim( @Unique( Subject : @If( @IsError( _lkp ) ; "" ; _lkp ) ) )

Damit steht im Feld immer das Dokument selbst mit drin...

Über Sinn und Unsinn einer solchen Implementierung diskutiere ich allerdings nicht (die Daten in dem Feld sind ja ständig veraltet wenn andere Dokumente erstellt, geändert, oder gelöscht werden)

Grundsätzlich ist zu sagen: Einen @DBLookup benutzt man NIE, ohne ihn in ein @IsError zu wrappen... sonst hast Du im besten Fall Fehler im Feld, im dümmsten Fall geht wegen des fehlerhaften Lookups das ganze Dokument nicht mehr auf...
Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen... das klingt dann so: "Tooode" (langes O, das r, s und n werden verschluckt, das t wird zum badischen d)

Offline Obrac

  • Senior Mitglied
  • ****
  • Beiträge: 277
  • Geschlecht: Männlich
@Tode: Ich zitiere mich einmal selbst:
Zitat
Wenn ein neues Dokument angelegt und die Nummer dort eingetragen und das Doc gespeichert wird, gibt es erst einmal die Meldung "Serverfehler: Eintrag im Index nicht gefunden".

Dass das Doc gespeichert werden muss, damit es sich selbst findet, ist klar, aber auch nach der Speicherung hat es nur nach dem Refresh geklappt. Was halt seltsam ist, ist, dass es in einer anderen Maske exakt genauso gemacht wird und auch klappt. Mein Verdacht ist, dass die etwas komplexere Ansichtsauswahlformal in der betreffenden Ansicht etwas schwergängiger ist.
Wie du es anhand deines Beispiels beschreibst, soll es auch funktionieren, und, ja, man könnte auch die Werte aus dem Dokument selbst holen und die der anderen Docs dann durch @dblookup, da gebe ich dir Recht.

Nun aber, durch deinen Hinweis und Flachmanns, funktioniert es, da ich den NoCache-Parameter mit eingebaut habe.

Offline Tode

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 6.883
  • Geschlecht: Männlich
  • Geht nicht, gibt's (fast) nicht... *g*
Ich habe das gelesen. Aber BEIM Speichern bekommst Du eben die Fehlermeldung. Du musst danach NOCHMAL speichern, sonst bleibt die Fehlermeldung bestehen.

Das hat mit der Reihenfolge zu tun: ZUERST werden die Formeln berechnet, und DANN wird gespeichert.

Vielleicht hast Du ja in der anderen Applikation irgendwo ein automatisches zweites Speichern drin. ToolsRefreshselectedDocs berechnet einmal neu und SPEICHERT....

Kann sein, ich habe das falsch interpretiert und Du speicherst auch jetzt schon zweimal. Meine Aussage ist und bleibt: mit einmal speichern kriegst Du das nicht weg...
Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen... das klingt dann so: "Tooode" (langes O, das r, s und n werden verschluckt, das t wird zum badischen d)

Offline Obrac

  • Senior Mitglied
  • ****
  • Beiträge: 277
  • Geschlecht: Männlich
Zitat
Ich habe das gelesen. Aber BEIM Speichern bekommst Du eben die Fehlermeldung. Du musst danach NOCHMAL speichern, sonst bleibt die Fehlermeldung bestehen.

Das hat mit der Reihenfolge zu tun: ZUERST werden die Formeln berechnet, und DANN wird gespeichert.

Das stimmt schon, aber in dem Fall ist das nicht ganz so schlimm, da es ein verstecktes Feld ist und im Anschluss an das Speichern noch ein Skript ausgeführt wird, das unter anderem ein Computewithform und eine weitere Speicherung ausführt. Bevor ich den NoCache-Parameter eingefügt hatte, führte aber nicht mal das zur korrekten Neuberechnung des Feldes. Das klappt aber jetzt. Ein @IsError sollte aber trotzdem noch rein, da hast du recht.

Offline Tode

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 6.883
  • Geschlecht: Männlich
  • Geht nicht, gibt's (fast) nicht... *g*
Aber genau Da ist ja unter Umständen auch Deine Krux: "ComputeWithForm" geht von links nach rechts und von oben nach unten durch die Felder. Hast Du in einem Feld in Deiner Maske ganz oben eine Formel, die auf einen Error läuft, dann wird der Rest der Maske unterhalb des Feldes mit dem Fehler nicht mehr berechnet. Und wenn Du die Parameter entsprechend gesetzt hast, siehst Du in Deinem Script- Code noch nichtmal einen Fehler...
Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen... das klingt dann so: "Tooode" (langes O, das r, s und n werden verschluckt, das t wird zum badischen d)

Offline Obrac

  • Senior Mitglied
  • ****
  • Beiträge: 277
  • Geschlecht: Männlich
Ich weiß, allerdings ist das auch ein Phänomen in der Maske, das ich nicht ganz nachvollziehen kann: Der Feldinhalt hatte die Fehlermeldung ("Eintrag im Index nicht...), normalerweise bin ich es aber gewöhnt, dass Docs mit dem Fehler eine Messagebox mit er Fehlermeldung ausgeben und das Doc dann auch gar nicht speicherbar ist.

Kann es übrigens sein, dass, wenn zwei separate Tabellen nebeneinander stehen, Notes erst die erste Tabelle komplett berechnet und dann erst die zweite? Das würde in dem Fall auch erklären, warum einmal öfter speichern notwendig ist

Offline Tode

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 6.883
  • Geschlecht: Männlich
  • Geht nicht, gibt's (fast) nicht... *g*
Ja, das kann durchaus sein.... Und von wegen "Eintrag im Index...": Hast Du irgendwo ein @Text() um Dein Lookup- Ergebnis drin? Weil das wandelt den Error in den Text des Errors um... und damit wird das Dokument mit dem Fehler im Feld gespeichert und der Fehler ist nicht "Speicherverhindernd"
Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen... das klingt dann so: "Tooode" (langes O, das r, s und n werden verschluckt, das t wird zum badischen d)

Offline Obrac

  • Senior Mitglied
  • ****
  • Beiträge: 277
  • Geschlecht: Männlich
@Tode: Ja, in der Tat ist ein @Text in dem Feld. Wieder was gelernt  :)

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz