Tabellen definition hat sich geändert[gelöst]

Hallo,
wir bekommen häufig die Fehlermeldung im RTC das sich die Tabellendefinition geändert hat. Wenn sich die Tabelle die ich mir gerade anzeige geändert hat verstehe ich dies.
ABER

Ich schaue mir die Verkaufsübersicht an
Im Designer ändere und kompeliere ich die Tabelle 18 (Customer)
Nun erhalte ich im RTC die Meldund das sich die Tabelle "Sales Header" geändert hat.
Es hilft dann auch nur noch ein Neustart des RTC´s
Aktualisieren reicht leider nicht.


Mir fällt dazu nur ein, das die Tabelle 18 in der 36 als Releation bei einigen Feldern gentuzt wird ?

Ist dies bei euch auch so ?


Hat hier jemand eine Idee ?


gruss
Jörg

Zuletzt geändert von Jörg Nissen am 26. April 2021 08:52, insgesamt 1-mal geändert.

Hallo,

solche Meldungen kommen auch wenn Tabellen Referenzen haben. D.h. da Tabelle 36 einen Referenz auf Tabelle 18 hat (diverse Debitoren- Referenzen), wird auch die Tabelle 36 bei einer Änderung in 18 neu kompiliert (Du könntest ja eine Funktion in 18 geändert oder gelöscht haben, die in 36 benutzt wird)

Gruß Fiddi

Hallo,

ja es ist so, dass Tabellenanpassungen Auswirkungen auf andere Tabellendefinitionen haben und daher die Fehlermeldung kommt.
Daher mache ich Anpassungen nur im Entwicklungs-/Testsystem und lasse mir vom Kunden ein Wartungsfenster für das Echtsystemupdate einrichten, ansonsten behindert man mMn die User zu viel.
Generell sollte man ja eigentlich nicht am "offenen Herzen" (Livesystem) entwickeln, dann löst sich das Problem von alleine.

Gruß!

Hallo,
es handelt sich um die Entwicklungsumgebung, in der wir mit mehreren Entwicklern arbeiten, und uns somit gegenseitig teilweise behindern.

öhm - hast du eine konrete Frage, die noch zu beantworten ist?
Die Ursprungsfrage:

Ist dies bei euch auch so ?
Hat hier jemand eine Idee ?

wurde ja bereits 2mal beantwortet ;)

Hallo,
es handelt sich um die Entwicklungsumgebung, in der wir mit mehreren Entwicklern arbeiten, und uns somit gegenseitig teilweise behindern.

Und ihr nutzt auch öfters gleichzeitig den RTC? Dann wird sich das Problem wohl nicht verhindern lassen....
Man könnte höchstens wie bei der AL-Extensionentwicklung einzelne Bestandteile lokal entwickeln und erst später in die gemeinsame Codebasis übertragen.
Mit Docker hat man ja heutzutage schnell ein NAV/BC- System hochgezogen.

Wenn man - wie bei uns z. B. üblich - den Object Manager Advanced oder ähnliche Tools verwendet, dann ist es ganz normal, dass die Entwickler permanent den RTC mitlaufen haben.
Wir kennen das Problem zu genüge, und ja: Es nervt schon.
Ich könnte es ja verstehen, wenn eine solche Meldung kommt, wenn man etwas geändert und/oder gespeichert hat, aber diese Meldungen kommen auch schon, wenn man nur mal kurz in den C/AL-Code geschaut hat, ohne etwas zu ändern, kompilieren und/oder zu speichern.

Wir hatten ein ähnliches Thema schon 2007, als es noch gar keinen RTC gab. Seinerzeit lag es am Change Log.

aber diese Meldungen kommen auch schon, wenn man nur mal kurz in den C/AL-Code geschaut hat, ohne etwas zu ändern, kompilieren und/oder zu speichern.

Das Verhalten kenne ich seit ca. 3.60, wie dort schon erwähnt.

Hallo,
das diese Meldung kommt ist auch sinnvoll - auch wenn Sie nervt - kein Programm sollte mit alten Funktionen oder Datenstrukturen arbeiten um Fehler zu vermeiden.

Gruß Fiddi

Ich könnte es ja verstehen, wenn eine solche Meldung kommt, wenn man etwas geändert und/oder gespeichert hat, aber diese Meldungen kommen auch schon, wenn man nur mal kurz in den C/AL-Code geschaut hat, ohne etwas zu ändern, kompilieren und/oder zu speichern.

Ich kenne das Problem, dass die Änderungsmeldung auch kommt wenn gar nix geändert sondern nur in den Code geschaut wurde, ebenfalls, aber nur aus älteren Versionen, seit ca. NAV 2013 R2 eher nicht mehr. In neueren Versionen kommt die Meldung meiner Erfahrung nach nur bei tatsächlichen Änderungen, die irgendeine Tabelle betreffen, die indirekt im Rollencenter in irgendeinem FlowField einer Cue Table verwendet wird. Wenn man ein möglichst mageres RC benutzt dann hat man meiner Erfahrung nach das Problem auch eher nicht. So zumindest meine Erfahrung, hauptsächlich mit NAV 2017.

Meine Erfahrungen sind da leider umgekehrt.

Unter NAV5.0 konnte ich problemlos "mal eben" in den C/AL-Code einer Tabelle schauen.
Da konnte ich nicht nur in den C/AL-Code der Tabellen schauen, sondern auch C/AL-Code in Triggern und Funktionen ändern und speichern, ohne dass die Anwender eine Fehlermeldung erhielten.
Erst wenn ich Felder hinzufüge, ändere oder lösche erhielten die Anwender die Fehlermeldung bzgl. geänderter Tabellendefinitionen.

Unter NAV2017 reicht es aber schon, wenn man nur "mal eben" eine Tabelle im Design öffnet. Da habe ich noch gar nichts geändert, geschweige denn gespeichert oder kompiliert, schon erhalten die Anwender die Fehlermeldung.

Ich könnte verstehen, dass die Fehlermeldung erscheint, wenn ich (ohne eine Änderung vorzunehmen) ein Objekt kompiliere oder speicher, da dann die Object Metadata neu erstellt werden und auch indirekte Bezüge zu der Tabelle (durch Permissions, TableRelations, Record-Variablen, ...) neue Metadaten benötigen, aber doch nicht schon beim reinen Anschauen der Tabellendefinition.

Es ist, wie es ist, ob es uns gefällt oder nicht.
Es bleibt uns nichts anderes übrig, als es so hinzunehmen.

Hallo,

in NAV 2018 darf man wieder schauen ohne Fehlermeldung.

Das Änderungen nicht zu einer Fehlermeldung führen, ist durchaus heikel. Da kann ein NAV5-Client noch den ganzen Tag ohne "Probleme" mit dem falschen Code laufen, ohne eine Fehlermeldung zu bekommn.

Gruß Fiddi

Da kann ein NAV5-Client noch den ganzen Tag ohne "Probleme" mit dem falschen Code laufen, ohne eine Fehlermeldung zu bekommn

Das gilt natürlich auch andersrum: da spielt einer das Objekt mit dem fehlerhaften Code ein, der Client läuft aber immer noch mit dem alten "guten" Objekt

Hallo,

Das gilt natürlich auch andersrum: da spielt einer das Objekt mit dem fehlerhaften Code ein, der Client läuft aber immer noch mit dem alten "guten" Objekt

Natürlich. Du konntest oft zumindest kurz testen, ohne befürchten zu müssen, das es knallt.

Es ist halt wie überall, es gibt nicht immer nur Vorteile.

Gruß Fiddi