[gelöst] Debugger Error auf Commit

[Datenkultur]

Hallo zusammen,

ich wundere mich hier über den Debugger. Ich habe bei einem Kunden oft den Fall, das der Debugger erst beim Commit einen Fehler ausgibt.

Da kommen so Meldungen wie:

Die Verkaufsrechnungszeile existiert bereits.Identifizierende Felder und Werte:Belegnr.='DR0000005',Zeilennr.='10000'

oder

Die Gebuchte Belegdimension existiert bereits.Identifizierende Felder und Werte: Tabellen-ID='113',Belegnr.='DR0000003',Zeilennr.='20000',Dimensionscode='KOSTENSTELLE'

Warum kommen die Meldungen beim Commit und nicht bei den zugehörigen Inserts? Das Commit steht an einer völlig anderen Stelle ganz am Schluss der Routine.


Danke vorab für Eure Hilfe.

Zuletzt geändert von Datenkultur am 5. Mai 2011 16:44, insgesamt 1-mal geändert.

ich wundere mich hier über den Debugger.

Das tun wir doch alle

Warum kommen die Meldungen beim Commit und nicht bei den zugehörigen Inserts? Das Commit steht an einer völlig anderen Stelle ganz am Schluss der Routine.

Meinst du damit, der Debugger läuft nach dem fehlerhaften INSERT im Quelltext (viel) weiter? Das wäre mir neu.
Bekanntes Problem ist eher, dass der Debugger-Zeiger ein paar Zeilen höher oder tiefer steht, als er tatsächlich ist. Dies führt leicht zu Fehlinterpretationen.

Liebe Natalie,

Das tun wir doch alle

das habe ich schon vermutet.

Das der Debugger gern mal kurz vor oder nach dem angezeigten Punkt steht, hat mich auch schon des öfteren an den Rand des Selbstzweifels gebracht. Daran habe ich mich aber inzwischen gewöhnt. Leider springt in meinem Fall der Debugger tatsächlich erst an, wenn das ganze per Commit real werden soll. Die eigentlichen Fehler sind ganz wo anders. Teilweise sogar in anderen Objekten.

Ich werkel gerade an den Buchungsroutinen der Artikelverfolgung herum. Neben der ordentlichen Komplexität ist da leider auch noch sehr viel temporäres dabei. Es ist daher sehr umständlich den ganzen SourceCode im Kopf rückwärts zu verfolgen.

Kennt jemand das Phänomen, oder besser noch: Eine Lösung ?

Ich wäre normalerweise so vorgegangen:

1. Ich führe in NAV eine Funktion aus und stoße auf einen Fehler.
2. Ich aktiviere den Debugger (mit Breakpoint auf Triggern = Nein) und wiederhole den Vorgang.
3. Normalerweise springt der Debugger (wenn im Quelltext nicht frühere, von mir gesetzte Breakpoints enthalten sind) nun genau in die Fehlerzeile.
4. In diese Zeile setze ich mit F9 einen neuen Breakpoint und beende den Debugger.
5. Ich wiederhole den Vorgang. Der Debugger bleibt beim Breakpoint stehen und ich kann nun den Inhalt der Variablen auslesen.

In Schritt 3 öffnet sich dein Debugger erst in der COMMIT-Zeile?

Das hätte ich auch so gemacht. Geht nur leider nicht. Der Debugger hält erst auf dem Commit an. Der auslösende Fehler ist aber ganz woanders.

Kann mich nicht erinnern, dass ich das Problem schon hatte (gibt aber dafür genug andere )

Wenn es so gewesen wäre, hätte ich wohl folgendes probiert: großzügig Breakpoints verteilt und so die richtige Stelle nach und nach eingegrenzt.

Nun kennst du die Stelle aber schon. Wenn du unmittelbar davor einsteigst, dich mit F8 zeilenweise durchklickst - gehts nach der fehlerhaften INSERT-Zeile einfach weiter oder kommt der Debugger nun "zur Vernunft"?

kommt der Debugger nun "zur Vernunft"?

Kann der Vernüftig sein?

CodeUnit 80:
- Ich komme auf ein SalesInvHeader.INSERT;
- Der Primary Key ist "No.".
- Das Feld "No." hat den Wert "DR0000005".
- Der Wert "DR0000005" ist in der Tabelle bereits enthalten.
- Das Programm rudert heiter weiter
- Beim abschließenden Commit kommt folgender Fehler:

---------------------------
Microsoft Dynamics NAV
---------------------------
Die Verkaufsrechnungskopf existiert bereits.Identifizierende Felder und Werte:Nr.='DR0000005'
---------------------------
OK
---------------------------

Seltsam... Aber so steht es geschrieben...

Anmerkung: Der SalesInvHeader ist nicht temporär und es existiert auch keine lokale Variable gleichen Namens.

Anmerkung: Der SalesInvHeader ist nicht temporär und es existiert auch keine lokale Variable gleichen Namens.

Gibt es einen Variablennamen sowohl lokal als auch global, dann hat der lokale Vorrang. Schau dir die Werte also für die lokale Variable an.

Es gibt ja leider keine lokale Variable gleichen Namens. Das muss ich daher leider auch ausschließen.

Es gibt ja leider keine lokale Variable gleichen Namens. Das muss ich daher leider auch ausschließen.

Sorry, hatte mich einfach nur verlesen

In Navision gibt es schon immer den sogennnten "Write Buffer", d.h. es werden alle schreibenden Zugriffe gepuffert bis ein lesender Zugriff oder COMMIT erfolgt.

z.B.
Debitor A existiert bereits, B und C aber nicht.

Code:

Deb."No." := 'A';
Deb.INSERT;
Deb."No." := 'B';
Deb.INSERT;
Deb."No." := 'C';
Deb.INSERT;

DEB.FINDFIRST();

Erst bei DEB.FINDFIRST() wird die Verarbeitung mit der Fehlermeldung abgebrochen, dass Debitor A bereits existiert.

@Natalie: Vielen Dank für Deine Hilfe. Du hast bestimmt keinen Grund rot zu werden.
@jm: Was Du schreibst klärt das Phänomen. Auch Dir vielen Dank für Deine Hilfe.

Die Frage habe ich gestellt, damit ich mir nicht aus Unkenntnis unötige Arbeit beim Debuggen mache.

Immerhin kann ich solche Fehler jetzt leichter ausmachen, wenn ich bei komplexen Prozessen an strategisch günstigen Positionen einen Lesezugriff platziere.