[GELÖST] SETRANGE nach einem FINDFIRST

Hallo Zusammen,

angenommen folgender Code ...

Code:

Inventory.RESET;
Inventory.SETRANGE("Item No.","Item No.");
Inventory.SETRANGE("Location Code","Location Code");
IF codreserviertfuerAuftrag <> ' ' then begin
  Inventory.SETRANGE("res. Auftragsnr.", "codreserviertfuerAuftrag"); 
  IF Inventory.FINDFIRST THEN BEGIN
    Inventory.SETRANGE("res. Auftragsnr.", "codreserviertfuerAuftrag");
  END ELSE BEGIN
    Inventory.SETRANGE("res. Auftragsnr.", ' ');
  END;
end else begin
  Inventory.SETRANGE("res. Auftragsnr.", '');
end;
Inventory.SETRANGE("Source No.",'');
Inventory.SETRANGE(blabla, blablabla);
...


Zur Erläuterung:
Ich möchte eine Zwischenprüfung machen, ob es denn einen Inventory-Eintrag mit der reservierten Auftragsnummer gibt und falls ja, dann sollen weitere Filterkriterien kommen.
Ich möchte verhindern, dass codreserviertfuerAuftrag befüllt, aber dann später in der Inventory-Tabelle gar nicht ein Eintrag vorhanden ist, deswegen diese kurze Zwischenprüfung.

Geht es denn, dass ich - obwohl ein FINDFIRST durchgeführt wurde - ich einfach weiter durch Filterkriterien eingrenze?

Zuletzt geändert von MSNAVLerner am 1. August 2016 11:19, insgesamt 1-mal geändert.

Bei Filterung von mehreren Datensätzen immer FINDSET statt FINDFIRST verwenden. Ansonsten kann man nach Bedarf immer weiter eingrenzen.

Hallo,

wie wäre es mit IF NOT Inventory.ISEMPTY THEN BEGIN?

Das sollte eigentlich funktionieren.


Viele Grüße
Jan

Wenn man die Datensätze weiterverarbeiten möchte, ist NOT ISEMPTY genau das falsche . Mit ISEMPTY hat man nämlich nie einen mit einen Werten gegriffen und dem Record zugewiesen. Das ist nur zum performanten Sondieren, ob etwas vorhanden ist, die Felder des Datensatzes werden aber nicht ausgewertet.
http://www.navision-blog.de/blog/2007/06/03/navision-performance-optimierung-auf-dem-sql-server/
Danach muss also dann immer noch FINDSET/FINDFIRST/FINDLAST kommen.

Ich habe wohl die "kurze Zwischenprüfung" falsch verstanden.

Meine Idee war, perfomant abzuklappern, ob überhaupt weitergemacht wird

@Kowa: Mir geht es nur darum, ob überhaupt ein einziger vorhanden ist, deswegen FINDSET ... können natürlich ruhig mehrere sein, deswegen kommt an späterer Stelle auch ein FINDSET ...

Ich denke in meinem Fall wäre NOT ISEMPTY nicht falsch ... er soll nämlich in jedem Fall weiter filtern ... er wird auch was finden, die Frage ist nur ob er einen reservierten Eintrag findet oder einen frei verfügbaren ...

Das Problem ist, wenn ich hier keine Prüfung einbaue, wird er - da übergangsmäßig bei bestimmten Einträgen IMMER codreserviertfuerAuftrag befüllt sein wird, obwohl es keinen Inventory-Eintrag hierzu gibt - keinen finden ... in diesem Fall soll er frei verfügbare Einträge ziehen, denn sonst zieht er keinen aus dem Lager.