Problem beim RENAME

Hallo,

ich würde gern rausbekommen, ob das bei uns auftretende Phänomen ein generelles Problem ist oder es irgendwo tiefer an unserer Anwendung oder unserer Konfiguration liegt:

Wir haben das Problem, daß nach Eingabe von Daten in der ersten Zeile einer nicht-Standard-Form oft eine Meldung auf dem Bildschirm erscheint 'Die Datensätze in Tabelle .... werden geändert'; dies erscheint mehrere Sekunden und es werden jeweils mehrere Tabellen der Datenbank nacheinander benannt. Nur, es sind nicht jedesmal die gleichen Tabellen und... die benannten Tabellen in denen angeblich Datensätze geändert werden haben zu 80 % keinen Zusammenhang zum bearbeiteten Bereich. Lästig nur die Verzögerung, zumal einige Kollegen über VPN Zugriff nehmen, da dauert es dann ewig...

Nun habe ich nach einiger Forschungsarbeit herausgefunden, daß dieses Phänomen anscheinend an einem RENAME hängt. Und es tritt jeweils nur beim ersten Durchlauf des RENAME in der geöffneten Session auf; jeweils also nur beim ersten Aufruf des RENAME nach Anmeldung an der Datenbank. Danach klappt alles reibungslos; das RENAME wird abgearbeitet ohne diese Meldung.

Ich habe das RENAME nun testweise ersetzt und siehe da, das Problemchen ist anscheinend behoben...

Achja, wir haben NAV 4.0 SP1 im Einsatz...

Hat jemand Erfahrungen mit diesem Phänomen ? Könnte es ein Bug des SP sein ?

Hi!

Sobald in einem bestehenden Datensatz der Wert eines Feldes geändert wird, welches Teil des Primärschlüssels ist, muss ja bekanntlich ein RENAME genutzt werden weil ein MODIFY hier nicht funktionieren würde. Sobald ein RENAME durchgeführt wird, werden sämtliche Felder aller Tabellen durchforstet und geprüft, ob eine TableRelation zu dem Feld (das Feld, welches geändert wird) hinterlegt ist. Ist dies der Fall, wird auch dort eine Änderung durchgeführt.

Durch was hast du denn das RENAME ersetzt?

Gruß, Marc

Das fände ich auch spannend, durch was man einen RENAME ersetzen kann.

RENAME ersetzen:

- TRANSFERFIELDS des alten Satzinhaltes in einen temporären Satz
- Ändern des/r Schlüsselfeldes/r im temporären Satz
- DELETE des alten Satzes
- INSERT des temporären Satzes

Sobald ein RENAME durchgeführt wird, werden sämtliche Felder aller Tabellen durchforstet und geprüft, ob eine TableRelation zu dem Feld (das Feld, welches geändert wird) hinterlegt ist. Ist dies der Fall, wird auch dort eine Änderung durchgeführt.

Also die angeblich zu ändernden Tabellen haben nicht wirklich eine TableRelation zu den Tabellendaten, die in der betroffenen Form bearbeitet werden. Vorstellbar ist jedoch, daß in allen bei unserem Problem angezeigten angeblich zu ändernden Tabellen eine TableRelation zu anderen Tabellen besteht in der aber der Feldname (z.B. 'Document No.') enthalten ist. Will sagen, vielleicht will NAV ja in allen Tabellen, in denen eine TableRelation zu egalwelcher anderen Tabelle besteht aber der Feldname (z.B. 'Document No.') in der TableRelation enthalten ist die Daten anpassen? Und warum nur beim ersten RENAME nach Anmeldung an der Datenbank ?

Handelt es sich bei deiner Tabelle um eine NAV Standard-Tabelle oder um einen individuelle?

Wenn Standard, welche Tabelle und welches Feld wird geändert?

Es handelt sich um eine Tabelle aus einer Branchenlösung...

Und du bist sicher, dass es keine TableRelations in anderen Tabellen gibt, die auf das Feld zeigen, welches du per RENAME änderst?

IMHO verhält sich der RENAME schon so, wie Marc es beschrieben hat.

Wenn der Primärkey deiner Tabelle aus nur einem Feld besteht, reicht es aus, wenn in einer anderen Tabelle als TableRelation nur deine Tabelle , ohne Spezifikation eines Feldes angegeben ist. Das impliziert dann eine TableRelation auf das Primärkeyfeld deiner Tabelle.

Mach dir mal eine Form auf die virtuelle Tabelle "Field" und filtere mal in der Spalte "RelationTableNo" auf die ID deiner Tabelle.

Danke für den Tip.

Also, der Primary Key besteht aus mehreren Felder, u.a. einem Feld 'Document No.', welches manchmal beim INSERT zunächst leer bleibt und erst nach Abschluß der Eingabe gefüllt ist (das ist aber nicht das aktuelle Problem). Deshalb das RENAME...

Die Form auf die virtuelle Tabelle "Field" hab ich gebaut; demnach gibt es aber nichtmal eine einzige Tabelle, die eine TableRelation zu der betroffenen Tabelle (auf die das RENAME läuft) hat...

Der Tip ist aber gut und die Form sicherlich auch für andere Recherchen nützlich...

Die "Document No." hat also keine Beziehung zu anderen Belegen im System?

Abreitet Ihr auf einer Native oder einer SQL DB?

Wir arbeiten mit SQL DB, dort kommt auch die Meldung von wegen 'Die Datensätze in Tabelle .... werden geändert'. Habe lokal noch eine NAV Version 4.0 SP1 auf einer Native DB; dort kommt die Meldung nicht aber es ist ebenfalls eine deutliche Zeitverzögerung durch das RENAME aufgetreten, welche ich durch die Ersatzkonstruktion beheben konnte.

Sorry, aber dann fällt mir auch nichts konstruktives mehr ein.

Du kannst höchstens mal euer NSC drauf ansetzen, die können auf den NAV Support zurgreifen.

Genau wegen der möglichen Table-Relation wird ja der Rename Befehl verwendet.
Beispiel du änderst den Code für ein Lager, dann wird automatisch in allen Tabellen, in denen das lager per Lookup ausgewählt und eingetragen werden kann, der Code ebenfalls geändert.
Mit Deiner Methode wird das umgangen und es könnte zu inkonsistenzen führen, wenn wirklich eine Table-Relation besteht.
Dazu muss die Funktion alle Tabellen durchsuchen, ob dort eine Table-Relation besteht. beim ersten rename nach dem Navision start müssen diese erst mal aus der Tabelle Objekt geladen werden. deshalb sieht man die Meldung, danach ist die Tabelle Objekt im Cache und alle weiteren Renames gehen sehr schnell wenn nicht wirklich viele Daten geändert werden müssen. Das geht so schnell, dass man die Meldung gar nicht mehr sieht.

Hallo Michael,

danke für Deinen Hinweis. Die Berechtigung des RENAME stelle ich keinesfalls in Frage. Ich würde auch auf gar keinen Fall empfehlen, jedes Rename zu ersetzen... das war ja nur aus dem einen Grund, herauszufinden, ob das Rename tatsächlich an den Verzögerungen Schuld ist.

Nach Deiner Ausführung und meinen Erkenntnissen muß ich jetzt folgern, daß allein das Laden aller Tabellen aus der Tabelle Objekt in den Cache zur Meldung 'Die Datensätze in Tabelle...werden geändert' führt. Das wäre ja dann tatsächlich ein Bug, weil beim Laden ja noch keine Daten geändert werden...

Ich hab auf meiner lokalen Native-Datenbank (an die SQL kam ich da nicht ran...) am Freitag noch einen kurzen Test gemacht mit einer Rename-Programmierung auf eine andere Tabelle und ebenfalls die Verzögerung bei erster Ausführung nach Anmeldung an die DB festgestellt (dort kommt keine Meldung, wie bereits oben gepostet).

Vielleicht hat mal jemand Zeit und Muße, auf einer SQL-Datenbank auch eine Rename-Ausführung auf eine nicht mit TableRelations verbundene Tabelle zu provozieren. Wäre interessant, ob das gleiche Problem auch in neueren NAV Versionen auftritt ...

DYNAMICS-ML hat geschrieben:Nach Deiner Ausführung und meinen Erkenntnissen muß ich jetzt folgern, daß allein das Laden aller Tabellen aus der Tabelle Objekt in den Cache zur Meldung 'Die Datensätze in Tabelle...werden geändert' führt. Das wäre ja dann tatsächlich ein Bug, weil beim Laden ja noch keine Daten geändert werden...

Nur vom Laden von Daten selbst werden natuerlich keine Daten geændert.
Es kommt nun natuerlich auch noch darauf an, was in den Triggern der Form steht - zum Beispiel im OnOpenForm usw.

Warum wird nicht erst ein INSERT gemacht, wenn alle Primærschluesselfelder gefuellt sind?
Oft hilft es, die Reihenfolge der Spalten so anzuordnen, dass zuerst alle Primærschluesselfelder gefuellt werden.
Uuuuund: "DelayedInsert" als Property der Form!

Vielleicht sollte man aber ueberhaupt erstmal mit dem Debugger das Fenster øffnen, um zu sehen, was beim Øffnen und dann beim Einfuegen des ersten Satzes alles aufgerufen wird.
Oder mit CodeCoverage und danach gucken, was alles durchlaufen wird und ggf. wie oft - kann auch helfen.

Aber um hier mehr helfen zu kønnen, muesste man natuerlich die Tabelle und Form sehen. Zumal es kein Standard ist - da kann man ja nur raten.
Denn programmiert werden kann schliesslich soooo vieles... :wink:

Viel Glueck!