MSDynamics.de

Hallo Community,

ich habe ein für mich wirklich überraschendes Problem. Scheinbar übersehe ich etwas.

Code:

recVKKopf.setrange("Nr.", "gesuchteNr.");
recVKKopf.setrange("gesperrt, FALSE);
IF recvkkopf.findfirst THEN BEGIN
  recVKKopf2 := recVKKopf;
  recVKKopf2.gesperrt := TRUE;
  recVKKopf2.MODIFY(TRUE);
END;


Das Beispiel ist fiktiv ausgedacht. Ich habe sowas schon öfters umgesetzt, doch diesmal spuckt er mir folgende Fehlermeldung aus.

Hallo,

schöner Fehler

Das Problem ist, dass du einen Datensatz ändern möchtest, bei dem eine Meldung erscheinen würde(RUNMODAL- Dialog, z.B. Kreditlimit- oder Bestandswarnung ), bevor du einen Commit gemacht hast.
Das darf nicht passieren, da du damit das ganze System blockieren könntest, weil die Meldung den/die gesperrten Datensätze blockieren würde.

Lösung:
Nach dem Dialog suchen, der die Meldung verursacht, verhindern das die Meldung erscheint.

Es ist in den seltensten Fällen eine gute Idee, einfach ein COMMIT einzufügen, da hierdurch verhindert wird, das durch auftretende Fehler die Transaktion korrekt zurück gedreht wird.

Gruß Fiddi

MSNAVLerner hat geschrieben:Das Beispiel ist fiktiv ausgedacht.

Es passt überhaupt nicht mit der Fehlermeldung zusammen. Kannst du bitte das Beispiel entweder verfeinern (da fehlen doch Aufrufe o.ä.) oder am besten gleich den Originalcode zeigen?

Es passt überhaupt nicht mit der Fehlermeldung zusammen. Kannst du bitte das Beispiel entweder verfeinern (da fehlen doch Aufrufe o.ä.) oder am besten gleich den Originalcode zeigen?

Nun das Beispiel könnte schon funktionieren, wenn du "Gesperrt" mit Validate zuweist.

Gruß Fiddi

Ich habe weder in der Form (da ist editable = no), noch in der Table Validatefunktion irgendwas an Code stehen.
Deswegen bin ich ja verwundert.

Dann gibt es eine Programmierung im Modify Trigger der Tabelle, welches ein RUNMODAL auslöst!

VG
Robert

Ich habe weder in der Form (da ist editable = no), noch in der Table Validatefunktion irgendwas an Code stehen.
Deswegen bin ich ja verwundert.

Der Fehler kann einer ganz anderen Stelle sein, das lässt sich nur durch einbauen von temporären COMMITS lokalisieren. Der Fehler tritt zwischen dem letzten und dem aktuellen COMMIT auf. Du musst jetzt durch die Commits den Bereich eingrenzen.

HINWEIS: Das ganze bitte nicht auf einer ECHT- DB machen, weil dadurch Daten verfälscht werden können.

Gruß Fiddi

Commits braucht man dafür nicht! Davon würde ich ganz klar abraten. Es reicht Step by Step Messages einzubauen, die nur unter einer Benutzerid laufen. Dann stört man auch keine Anwender. Das problem liegt dann immer hinter der letzten angezeigten Message.

Wer Commits einbaut erzeugt nur Datenschrott (ob Test oder Echtsystem ist dabei doch egal). Den administrativen Aufwand eine Testdatenbank, danach neu aufzubauen oder zu bereinigen, kann man sich sparen.

Code:

IF UPPERCASE(USERID) = 'ROBERTW' THEN
  MESSAGE('1: Step1');

...

IF UPPERCASE(USERID) = 'ROBERTW' THEN
  MESSAGE('2: Step2');

...

IF UPPERCASE(USERID) = 'ROBERTW' THEN
  MESSAGE('3: Step3');


rwendler hat geschrieben:Dann gibt es eine Programmierung im Modify Trigger der Tabelle, welches ein RUNMODAL auslöst!

Das habe ich im Codebeispiel ausversehen "falsch" rein geschrieben.
Ich rufe MODIFY ohne TRUE auf. Im MODIFY werden "Geändert von", "Geändert am", "Geändert um" gesetzt.

Ich entwickle nur auf meinem lokalen Testsystem.
Es führt wohl kein Weg dran vorbei Step by Step über MESSAGES zu suchen.

Hallo,

soviel ich weiß ist ein MESSAGE nicht Modal, und damit kein Problem für die Funktion. Alternative wäre evtl. ein CONFIRM, das könnte eine Lösung sein.

Gruß Fiddi

Die Message läuft nicht modal. Das ist korrekt. Allerdings spielt das in dem Fall auch keine Rolle?! Die Messages werden ja trotzdem ausgeführt und anhand des Inhaltes kann man nach dem Fehler sehen, welche Messages ausgeführt worden sind.

Ein Confirm würde natürlich auch gehen :)

VG
Robert