[gelöst] rec.COUNT =1, aber KEIN findlast? (CC)

24. Februar 2020 13:00

Hallo ihr Lieben,

ich habe mal wieder ein Problem, bei dem mir im Betrieb keiner helfen kann :(

Code:
getItemProposalPartNo(varSerialNumber : Code[15];varIdentifier : Code[10]) varPartNo : Code[20]

CLEAR(lrc_ItemProposal);
lrc_ItemProposal.RESET;
IF (varIdentifier = 'IMEI') THEN lrc_ItemProposal.SETRANGE(imeiNo,varSerialNumber);
IF (varIdentifier = 'MSN') THEN lrc_ItemProposal.SETRANGE(serialNo,varSerialNumber);
lrc_ItemProposal.SETRANGE(processingStatus,lrc_ItemProposal.processingStatus::successful);
IF (lrc_ItemProposal.COUNT >0) THEN  MESSAGE('Anzahl Ergebnisse: ' + FORMAT(lrc_ItemProposal.COUNT));
IF lrc_ItemProposal.FINDLAST THEN 
BEGIN
    MESSAGE(lrc_ItemProposal.itemNo);
    EXIT(lrc_ItemProposal.itemNo);
END ELSE EXIT('');


Und zwar gibt der mir bei dem Count zurück, dass es einen Treffer gibt, allerdings geht der nicht in die "findlast".

Mein Ausbilder und ich haben bestimmt 45 Minuten zusammen gesessen zum Testen und wissen einfach nicht weiter, vielleicht kann mir jemand von euch helfen. :)

Vielen Dank schon mal und verzweifelte Grüße
Sassi
Zuletzt geändert von Sassi91 am 24. Februar 2020 15:04, insgesamt 1-mal geändert.

Re: rec.COUNT =1, aber KEIN findlast? (CC)

24. Februar 2020 13:17

Hm, seltsam.

Wie ist denn überhaupt die Datenlage; stimmt das Ergebnis 1 überhaupt? Stimmen eure Filter (laut Debugger)?

Re: rec.COUNT =1, aber KEIN findlast? (CC)

24. Februar 2020 13:28

Hallo,

ich habe (wie Natalie) etwas erstaunt auf den Programmcode geschaut und gedacht, dass das eigentlich funktionieren sollte.
Vielleicht liegt das Problem aber am COUNT.
Der Beitrag auf mibuso ist zwar schon etwas älter - aber eure NAV-Version ja auch :wink:

https://forum.mibuso.com/discussion/34704/count-issue

Re: rec.COUNT =1, aber KEIN findlast? (CC)

24. Februar 2020 13:35

Hallo,

ich denke du hast es geprüft, aber ein "lrc_ItemProposal.itemNo" mit Wert '' (leer) gibt es nicht?

Dann würde ich prüfen, ob es lokale und globale Variablen mit dem gleichen Namen gibt.

Wie ist denn der Schlüssel der Tabelle?

Die Tabelle wird auch nur von NAV- verwaltet, also nicht aus einem externen System gefüttert?

Gruß Fiddi

Re: rec.COUNT =1, aber KEIN findlast? (CC)

24. Februar 2020 13:41

Wenn du die Reihenfolge tauschst, also zuerst findlast und dann die Ausgabe von count: verhält sich das dann gleich?

Re: rec.COUNT =1, aber KEIN findlast? (CC)

24. Februar 2020 14:32

Vielen Dank erstmal für eure Antworten :)

fiddi hat geschrieben:ich denke du hast es geprüft, aber ein "lrc_ItemProposal.itemNo" mit Wert '' (leer) gibt es nicht?

doch, gibt es, aber nicht zu der IMEI.

fiddi hat geschrieben:Dann würde ich prüfen, ob es lokale und globale Variablen mit dem gleichen Namen gibt.

Es gibt nur ganz wenig globale Variablen, schon gecheckt. :)

fiddi hat geschrieben:Wie ist denn der Schlüssel der Tabelle?
eine fortlaufende id

fiddi hat geschrieben:Die Tabelle wird auch nur von NAV- verwaltet, also nicht aus einem externen System gefüttert?
Die Tabelle, von der ich die Daten hole, wird von der Apple-Schnittstelle z.B. "gefüttert" und liefert mir unter anderem den Artikelnamen und -Nummer zurück. Die Tabelle ist aber innerhalb 2 Sekunden gefüllt und der Status auf "successful". Ich mache diese Abfrage mit Abstand einer Sekunde immer wieder (30sek lang) und nie gibt er einen Wert zurück, aber sehr früh schon, dass es eine Zeile gibt (durch Count).

Natalie hat geschrieben:Wie ist denn überhaupt die Datenlage; stimmt das Ergebnis 1 überhaupt? Stimmen eure Filter (laut Debugger)?

ja, genau ein Ergebnis ist in diesem Fall gewünscht und auch beim manuellen Durchsehen der Tabelle zu sehen...

Re: rec.COUNT =1, aber KEIN findlast? (CC)

24. Februar 2020 14:54

Das Ding ist auch, wenn ich vor der FINDLAST den processingstatus ausgeben lasse, sagt der mir 30 sekunden lang, dass der auf "pending" steht, obwohl ich nebenbei in der Tabelle nach 2 Sekunden "successful" (also auch Artikelnummer und -name gefüllt) gesehen habe. ich sehe meinen Fehler jedoch nicht - ich aktualisiere den Filter doch mit .RESET jedes mal :-?

McClane hat geschrieben:Wenn du die Reihenfolge tauschst, also zuerst findlast und dann die Ausgabe von count: verhält sich das dann gleich?

es ist egal, was ich in der FINDLAST ausgeben würde, da der angeblich keinen Eintrag findet und da nicht rein geht (habe ich mit MESSAGE('test'); getestet), aber auch in einer else sagt der mir, dass er einen Datensatz findet.
Code:
IF lrc_ItemProposal.FINDLAST THEN
  BEGIN
    MESSAGE('Count in der FINDLAST: %1',lrc_ItemProposal.COUNT);
    MESSAGE(lrc_ItemProposal.itemNo);
    EXIT(lrc_ItemProposal.itemNo);
  END ELSE BEGIN
    MESSAGE('Count in der ELSE (FINDLAST): %1',lrc_ItemProposal.COUNT);
    EXIT('');
  END;

Re: rec.COUNT =1, aber KEIN findlast? (CC)

24. Februar 2020 14:58

Versuchs mal mit SELECTLATESTVERSION for dem FINDLAST. Ist aber nur geraten.

Re: rec.COUNT =1, aber KEIN findlast? (CC)

24. Februar 2020 15:03

Natalie hat geschrieben:Versuchs mal mit SELECTLATESTVERSION for dem FINDLAST. Ist aber nur geraten.


DANKE DANKE DANKE!!!!

Nach sowas in der Art hab' ich gesucht, wusste nicht, dass es diesen Befehl gibt. Das hat mein Problem gelöst, nun spuckt der mir auch eine Artikelnummer aus :) :-D

Re: [gelöst] rec.COUNT =1, aber KEIN findlast? (CC)

24. Februar 2020 15:18

Hallo,

das hängt damit zusammen, das NAV nur alle 30 Sekunden den Cache aktualisiert.
Wenn die Daten also von extern kommen, dann kann es bis zu 30 Sek. dauern, bis NAV die Daten "sieht". Insbesondere dann, wenn die Transaktion nicht von NAV selbst ausgelöst wurde.

SELECTLATESTVERSION sorgt jetzt dafür, dass das schneller passiert. Den Befehl sollte man jetzt aber auch nicht zu oft anwenden, da er doch für ein wenig Last sorgen kann.

Gruß Fiddi

Re: [gelöst] rec.COUNT =1, aber KEIN findlast? (CC)

24. Februar 2020 15:36

Gut zu wissen, danke! Falls da Probleme bei Kollegen auftauchen, behalte ich das im Hinterkopf. :)