[Gelöst] Nach Änderung eines Objektes spinnt der Client

[Natalie]

An unserer Entwicklungsdatenbank in NAV 5.0 (SQL) geschieht folgendes:

Sobald ich irgend ein beliebiges Objekt ändere (also speichere) und nun z.B. versuche, einen Auftrag anzulegen (oder irgend eine andere DB-Transaktion auszuführen), wird dies mit folgender Fehlermeldung quittiert:

Ein anderer Anwender hat die Definition der Tabelle Field geändert, nachdem diese Aktivität begann.

Bitte beginnen Sie die Aktivität noch einmal.

Bezeichnend ist, dass es um die Tabelle "Field" geht.
Was der Debugger dazu sagt, seht ihr im Screenshot.

Ich muss dann jedes Mal den Client neu starten. Und dies nach jeder erneuten Änderung eines Objektes ....

Wir sitzen meist zu 3 Personen gleichzeitig an der Datenbank. Bei meinem Kollegen (also anderer Rechner) konnten wir das Problem reproduzieren.

Hat jemand eine Idee, wie man das abstellen kann?
Ich bin nicht die einzige, die das Problem hat (und bislang keine Lösung):
Siehe Dynamics User Group.

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Zuletzt geändert von Natalie am 21. Dezember 2007 17:58, insgesamt 1-mal geändert.

Also, bei uns hat im 4.02 geholfen mit Alt+F1 die Navi-Bar zu- und wieder aufzumachen. Leider keine andere Lösung...

Das Problem ist das Änderungsprotokoll, wenn ein Feld, das überwacht wird, nicht mehr existiert, dann knallts, weil das Änderungsprotokoll ja ständig im Cache ist,....
Abhilfe schafft, wenn du vor der Bearbeitung von Tabellen (nur da sollte das Problem auftauchen) das Change Log ausschaltest, danach die Log-definition aktualisiert und dann wieder einschaltest.

Danke Michael, das wars tatsächlich.
Aber damit geb ich mich noch nicht zufrieden, weil es unser Kunde ggf. auch nicht sein wird:

Spätestens beim Kunden muss das Änderungsprotokoll unbedingt aktiviert sein, weil eines unserer Module darauf basiert.
Er wird natürlich ab und an Objektupdates von uns bekommen - muss ich dann auch erwarten, dass es knallt?
Ist dies Change Log Management unsauber programmiert oder was genau passiert da eigentlich?

Hallo Natalie,

wenn zum oder spätestens nach dem Einspielen der Objekte die Anwender sich neu angemeldet haben, ist doch alles wieder im grünen Bereich, oder?

Oder wie geht Ihr beim Einspielen von Updates vor?
Ist sicher eine spannende Frage, denn gerade bei einer SQL-DB merkt der Anwender ja nicht unbedingt sofort, dass sich die Objekte geändert haben.

Die Objekte werden doch im laufenden Betrieb eingespielt (als fob-Datei).
Muss ich nun erwarten, dass die Benutzer, die schon vorher eingeloggt waren, nun auf diesen Fehler laufen?

Bei einem Objektupdate sagen wir unseren Kunden immer:
Wenn Du die Fob eingelesen hast, müssen ALLE Clients einmal neu gestartet werden, und wenn im Update relevante Felder hinzugekommen oder weggefallen sind sagen wir, dass anschließend der (von uns eingebaute) Änderungsprotokollassistent aufgerufen werden muss, bevor die anderen Clients wieder online gehen. Dann gibts das Problem nicht.

Bei einem Objektupdate sagen wir unseren Kunden immer:
Wenn Du die Fob eingelesen hast, müssen ALLE Clients einmal neu gestartet werden, und wenn im Update relevante Felder hinzugekommen oder weggefallen sind sagen wir, dass anschließend der (von uns eingebaute) Änderungsprotokollassistent aufgerufen werden muss, bevor die anderen Clients wieder online gehen. Dann gibts das Problem nicht.

Dann hast du uns einiges voraus

Ich hab gegrübelt, warum zum Henker dieses Problem dann nicht schon viel früher aufgetaucht ist ... Lösung: Ich glaube, alle anderen Kunden (mit denen ich zu tun hatte) nutzen das Änderungsprotokoll gar nicht :-/

Das kann schon sein, oder es werden nur einige ganz bestimmte Felder in ganz bestimmten Tabellen überwacht, solange die nicht geändert werden, passiert ja nix, da reicht ein einfacher Clientneustart, der ja sowieso erforderlich ist, damit die Leute die geänderten Objekte überhaupt mitbekommen. was schon im Cache ist, wird ja nicht mehr geprüft.
Hab ich oft genug gehabt:
Rechnungsformular wurde angepasst, Fob zum Kunden, der liest ein, testet, alles Klar. 5 Minuten später Anruf, wenn Mitarbeiter XY Rechnung druckt ist da das alte Formular......

Aber ich habe gar keine Felder gändert:
Es reichte schon,wenn ich im Documentation-Trigger eine Leerzeile eingefügt und das abgespeichert habe ...!

Zum Programmieren kann man das Änderungsprotokoll ja ohne weiteres ausschalten. Damit hast Du das Problem nicht, und die Kunden starten nach einem Update eben ihre Clients neu und gut ist....

Klar, das habe ich ja auch mit sofortiger Wirkung getan

Aber kannst du mir erklären, warum es für den Fehler ausreicht, wenn ich ein Table-Objekt einfach ohne Feldänderungen abspeichere ?

Es reicht oft auch aus, eine Tabelle einfach im Designer zu öffnen, ein wenig rumzuscrollen und wieder mit ESC zu verlassen. Dann hast du das gleiche Phänomen...

@silverX:
auch ohne Speichern?

@Natalie:
Ich vermute, dass das an der Tabelle Object liegt, in der ja der Datensatz geändert wird, wenn man ein Objekt abspeichert. Warum Navision dann aber sagt, dass die Definition der Tabelle Field geändert wurde, wissen wahrscheinlich nicht mal die Dänen, du kannst ja einen Support Call aufmachen und mal nachhören....

Warum Navision dann aber sagt, dass die Definition der Tabelle Field geändert wurde, wissen wahrscheinlich nicht mal die Dänen, du kannst ja einen Support Call aufmachen und mal nachhören....

lol Die platzen gerade aus allen Nähten ... Bis ich von denen ne Antwort erhalte, weiß ich es selber

@Michael: Ja, auch ohne speichern. Kann ich hier regelmäßig reproduzieren...

Mit den älteren Clients musste man die Tabelle speichern, damit die anderen User mit Definitionsänderungen genervt wurden, aber ich glaube , es kam mit Version 3.60, dass das Öffnen und Scrollen schon reicht. Neue Freunde macht man sich damit nicht, wenn man im Echtsystem am Werkeln ist.

Hallo zusammen,

gibt es mittlerweile zufällig schon Lösung dafür z.B. in Nav 2009?

gibt es mittlerweile zufällig schon Lösung dafür z.B. in Nav 2009?

Nicht wirklich. Im CC reicht es im Alg. die Datenbank neu zu öffnen 'Datei/den gerade geöffneten Mandanten auswählen" im RTC habe ich dieses Phänomen noch nicht beobachten können. Für den NAS hilft da wahrscheinlich nur neu starten.

Gruß, Fiddi

Ich habe eine Lösung gefunden.
Wenn ich die Protokollierung für Table Change Log Setup (Field) in Change log Management ausschalte,

Code:

IsLogActive(TableNumber : Integer;FieldNumber : Integer;TypeOfChange : 'Insertion,Modification,Deletion') : Boolean
IF TableNumber IN
   [DATABASE::"Change Log Setup",DATABASE::"Change Log Setup (Table)"]
    //DATABASE::"Change Log Setup (Field)"]
THEN
  EXIT(TRUE);


dann erhalte ich die Fehlermeldung vom Tabelle Field nicht mehr und aber nur vom tatsächlich betroffenen Tabelle. Ich denke dass ich mit dieser Lösung leben kann.

Ich habe eine Lösung gefunden.
Wenn ich die Protokollierung für Table Change Log Setup (Field) in Change log Management ausschalte,

Code:

IsLogActive(TableNumber : Integer;FieldNumber : Integer;TypeOfChange : 'Insertion,Modification,Deletion') : Boolean
IF TableNumber IN
   [DATABASE::"Change Log Setup",DATABASE::"Change Log Setup (Table)"]
    //DATABASE::"Change Log Setup (Field)"]
THEN
  EXIT(TRUE);


dann erhalte ich die Fehlermeldung vom Tabelle Field nicht mehr und aber nur vom tatsächlich betroffenen Tabelle. Ich denke dass ich mit dieser Lösung leben kann.

Kann mir einer sagen, was diese Änderung genau für Auswirkungen hat?

Das Thema ist zwar schon relativ alt, aber wir haben grade das gleiche Phänomen.
Mich würde auch interessieren, was die vorgeschlagene Codeänderung sonst noch für Konsequenzen hat.
Die Änderungsprotokollierung an sich sollte schon funktionieren.

Ich habe eine Lösung gefunden.
Wenn ich die Protokollierung für Table Change Log Setup (Field) in Change log Management ausschalte,

Code:

IsLogActive(TableNumber : Integer;FieldNumber : Integer;TypeOfChange : 'Insertion,Modification,Deletion') : Boolean
IF TableNumber IN
   [DATABASE::"Change Log Setup",DATABASE::"Change Log Setup (Table)"]
    //DATABASE::"Change Log Setup (Field)"]
THEN
  EXIT(TRUE);


dann erhalte ich die Fehlermeldung vom Tabelle Field nicht mehr und aber nur vom tatsächlich betroffenen Tabelle. Ich denke dass ich mit dieser Lösung leben kann.

Kann mir einer sagen, was diese Änderung genau für Auswirkungen hat?

Wenn man die Einstellungen im Änderungsprotokoll ändert (aktiviert, deaktiviert, Tabellen/Felder für die Protokollierung hinzufügt usw.) dann will das Änderungsprotokoll diese Änderungen IMMER protokollieren, auch wenn das Änderungsprotokoll an sich nicht aktiviert ist, deshalb gibt die Funktion IsLogActive() IMMER ein TRUE zurück, wenn es sich um die o.g. Tabellen in der IF TableNumber IN - Abfrage handelt. Die Änderung von navsyst umgeht diese Logik zumindest für die Tabelle "Change Log Setup (Field)".

Danke für die Eerklärung.

Gruß