! Neue Felder können Standard ohne Codeänderung verändern !!

Hallo zusammen,

mir ist ein interessantes Verhalten im Zusammenhang mit WITH-Anweisungen des Standards aufgefallen, welches unbedingt bei der Entwicklung beachtet werden sollte:

Werden in Standardtabellen neue (Individual-)Felder hinzugefügt mit Namen, die im Standard ebenso verwendet werden, kann es im Code von Objekten, welche gar nicht geändert wurden, zu anderem Verhalten (Fehlern) kommen.

Beispiel:
In der Artikel-Tabelle wird ein Feld mit Namen "Location Code" angelegt. (Wenn man z.B. Artikel immer von einem Lagerort verkaufen will...)

Daraufhin wird in Tabelle 7326 "Whse. Worksheet Line" in der Fkt. CalcAvailableQty() dieses Feld dann fehlerhafterweise verwendet, ohne dass dort Code manuell verändert wird ! Die Neuanlage des Feldes reicht schon aus. Das Feld liegt nun im Gültigkeitsbereich der WITH-Anweisung und wird vorrangig vor dem ursprünglichen Feld der T7326 verwendet. Siehe folgenden Code:

Code:

    PROCEDURE CalcAvailableQty@1() AvailableQty@1000 : Decimal;
    VAR
      Item@1002 : Record 27;
      AvailableQtyBase@1001 : Decimal;
      AvailableWMSQtyBase@1004 : Decimal;
    BEGIN
      IF NOT Item.GET("Item No.") THEN
        EXIT;

      WITH Item DO BEGIN
        SETRANGE("Location Filter","Location Code");   // <==  !!!
        SETRANGE("Variant Filter","Variant Code");
        SETRANGE("Wksh.-Template Name Filter","Worksheet Template Name");
        CALCFIELDS(
          Inventory,
          "Qty. Received not available",
          "Qty. Assigned",
          "Qty. Assigned to pick",
          "Reserved Qty. on Inventory",
          "Qty. Picked");
        GetLocation("Location Code");     // <== !!!
        IF Location."Use Zones and Bins" THEN BEGIN
          AvailableWMSQtyBase :=
            CalcAvailWhseQtyBase("Location Code","Item No.","Variant Code","Unit of Measure Code");     // <==  !!!
          AvailableQtyBase :=
            AvailableWMSQtyBase - "Qty. Assigned";
        END ELSE BEGIN
          AvailableQtyBase :=
            Inventory - "Qty. Received not available" - "Qty. Assigned"  -
            "Qty. Assigned to pick" - ABS("Reserved Qty. on Inventory") + AssignedQtyOnReservedLines - "Qty. Picked";
        END;

        SETRANGE("Location Filter");
      END;

      AvailableQty := CalcQty(AvailableQtyBase);
    END;


Zum Fehlverhalten würde es erst kommen, wenn das Objekt neu kompiliert wird.
Das ist aber sehr wahrscheinlich, da man generell oft alle Objekte der DB durchkompiliert um Codekonsistenz zu wahren.

Zu merken ist also, wenn man in Standardtabellen neue Felder mit im Standard gebräuchlichen Namen verwendet, sollte man diese anders benennen oder zumindest nachträglich mit einem Tool prüfen, wo es Auswirkungen haben könnte. Hierzu eignet sich sehr gut der "Objekt Manager Advanced" von IDYN.

Wenn man wirklich auf der sicheren Seite sein will, ist eine andere Namensgebung auf jeden Fall der bessere Weg, auch hinsichtlich zukünftiger Änderungen/Erweiterungen des Standards.

Viele Grüße
Oliver

Danke für den wertvollen Hinweis!
War mir so bisher auch nicht bewusst, aber jetzt wo ich es von dir lese, klingt das logisch und nachvollziehbar.
Da will man sich schon brav an die Namenskonventionen des NAV-Standards halten und wird dann so abgestraft.

Schön wäre es natürlich, wenn der Compiler hier eine Warnmeldung ausgiebt, welche einen darauf hinweist, dass das Feld sowohl im Rec, als auch der WITH-Variablen enthalten ist.
(Man wird ja wohl noch träumen dürfen.)

Das wäre sehr sinnvoll. Dann gäbe es auch gleich an anderen Stellen Warnhinweise, wenn z.B. eine lokale Variable den Scope einer globalen gleichen Namens überdeckt.

Träumen darf man - und die Hoffnung nie aufgeben auch ...

Das ist ein uraltes Problem in NAV. Aber im Zuge einer RTC-Umstellung werden natürlich immer mal wieder alle Objekte kompilliert, von daher ist das sehr wichtig, das hier noch einmal herauszustellen.

[Kowa]

Vielen Dank für die Ausführung, mir war das bis heute nicht bewußt.
Aber nun verstehe ich, warum manchmal vor dem Verwenden von WITH im eigen programmierten Code gewarnt wird.

Zuletzt geändert von Kowa am 16. September 2016 10:01, insgesamt 1-mal geändert.
Grund: Vollzitat entfernt, Verstoß gegen Community-Knigge

Aber nun verstehe ich, warum manchmal vor dem Verwenden von WITH im eigen programmierten Code gewarnt wird.

Ich wurde schon bei meiner ersten C/AL Schulung davor gewarnt und habe die WITH-Funktion deshalb gleich gedanklich "entsorgt" .

WITH kenne ich zwar, aber nie benutzt. Der Code wird bei langen WITH Bereichen ja doch etwas unleserlich.
Aber das ändert natürlich am Problem im Standard nichts.

Der Code wird bei langen WITH Bereichen ja doch etwas unleserlich.

Naja, eigentlich sollte das die Zeilen doch verkürzen. Nur leider löst NAV das Feld (selbst die mit eindeutigem Feldname) nicht mehr in der Statusleiste auf (wie beim Rec auf Tabellenebene auch), so daß man schnell mal nachgucken könnte. Auch "Go To Definition" (ab NAV 2009 R2) funktioniert hier nicht. WITH ist wirklich schlecht umgesetzt, von daher kann man eigentlich nur dem Rat von Kowa folgen.

Hallo,

das ganze gilt nicht nur für Felder, auch neue Funktionen können das Verhalten des Programms ändern. Deshalb sollte die Empfehlung sein, neue Funktionen nach Möglichkeit nur Lokal zu definieren, und erst bei Bedarf Global zu definieren.

Gruß, Fiddi