[gelöst] Datentyp Integer auf BigInteger ändern

Hallo miteinander.

Ich versuche seit zwei Tagen den Datentyp eines Feldes von Integer auf BigInteger zu setzen. Navision lässt das allerdings nicht zu, weil die Tabelle Datensätze enthält. Kann ich den Datentyp dieser Spalte trotzdem irgendwie abändern? Gibt es vielleicht Sicherheitsmechanismen die man deaktivieren kann?

Danke fürs Reinschauen

Gruß
Kai

Zuletzt geändert von Bongo am 17. August 2015 09:28, insgesamt 1-mal geändert.

Solche Schutzmechanismen kann man nicht ausschalten.

Wenn dieses Feld zum Standard gehört, muss man zuerst die komplette Anwendung durchleuchten, ob dieses irgendwo als Parameter in Funktionen verwendet wird oder Felder in anderen Tabellen mit TableRelations auf dieses Feld vorhanden sind und die alle ebenfalls anpassen. Bei eigenen Feldern natürlich prinzipiell analog, auch wenn es da vermutlich leichter fällt, die Verwendung zu überschauen.

Wenn das kein Primärschlüsselfeld ist, ein temporäres Zusatzfeld in diese Tabelle anlegen, für alle Datensätze die Feldwerte in dieses temp. Feld kopieren und gleichzeitig die Daten im Ausgangsfeld löschen. Dann das Feld umstellen und noch mal durch die ganze Tabelle und zurückschreiben und die Daten im temp. Feld löschen. Danach das temp. Feld wieder löschen.

Wenn das Feld Teil des Primärschlüssels ist, wird es aufwendiger, dann muss das temp. Feld bis zum Abschluss der Umstellung mit zum Primärschlüssel dazu. Da man hier die Feldinhalte nicht verändert, kann man ausnahmsweise auf das zeitaufwendige RENAME verzichten und den Datensatz im Batchlauf zur Laufzeit in eine zweite Instanz duplizieren und danach den alten löschen, so wie hier beschrieben.

Hallo und vielen Dank für die Antwort.

Ich hatte bereits ein temp.-Feld angelegt, alle Wert des zu ändernden Feldes da rein kopiert und die Werte in der Ausgangsspalte auf 0 gesetzt (CLEAR("Änderung Spalte")). Dann habe ich versucht den Datentyp zu ändern. Allerdings wird der Wert 0, so wie es aussieht, auch als Wert gesehen, der eine Änderung verhindert.
Es gibt auch eine Relation zu einer anderen Tabelle. Die hatte ich auch schon einmal gelöst und dann versucht, die Änderung zu machen - immer derselbe Fehler (sind Daten drin, geht nit).

Allerdings wird der Wert 0, so wie es aussieht, auch als Wert gesehen, der eine Änderung verhindert.

Ja, das ist so (erst ab R2), ich konnte das auf der leeren Key Buffer Tabelle nachvollziehen. Löschen kann man leere Felder aber schon, wenn sie nicht zum Primärschlüssel gehören.
Das würde ich dann so probieren:
Erst TableRelations anderer Tabellen lösen, das Originalfeld nach dem Kopiervorgang kurzfristig löschen (ab NAV 2013 R2 an dieser Stelle das Schema forciert synchroniseren) und mit der gleichen Feld-ID als BigInteger neu angelegen (bei R2 wieder Schema synchroniseren). Dann die Feldinhalte zurückschreiben und TableRelations wieder herstellen.

Die Idee mit dem Löschen der Spalte (Feld) habe ich auch schon einmal aufgegriffen. Allerdings weiß ich nicht, ob es Relationen von anderen Tabellen auf dieses Feld gibt. Kann ich das irgendwie herausfinden?
Und wie kann ich ein Schema synchronisieren? Bin noch nicht so erfahren in Navision.

Gruß
Kai

Das Ermitteln der TableRelations und vor allem das Auflisten der Verwendung in Funktionen erfordern einen Tool, wie den Object Manager (die Testversion läuft heute allerdings gerade ab).
Alternative wäre die Standardversion von Prism, Testversion läuft für 14 Tage, danach wird die zur funktionseingeschränkten Community Edition, dann geht das nicht mehr.

Für die Relations kann man zur Not auch manuell den Code durchforsten, dazu muss man alle Tabellen exportieren und nach
TableRelation="<Tabellename>" bzw. TableRelation="<Tabellenname>.<Feldname>" suchen.

Zum Thema Schemaänderungen habe ich hier einen FAQ-Artikel erstellt.

Gerade in NAV 2013 R2 sind Änderungen am Feldtyp aber eine extrem heikle Operation, weil man die Synchronisierung da nur ganz ab- oder anschalten kann (abgeschaltet kann man das Feld zwar umstellen, aber die gesamte Datenbank ist in diesem Zustand potenziell gefährdet, weil dann alle Änderungen erst mal akzeptiert werden, auch wenn sie zum Datenverlust führen würden), und ohne ausreichende Erfahrung mit NAV und PowerShell sollte man das nur an Testsystemen üben und für die Anwendung in Echtsystemen jemand mit Erfahrung dazuholen.

Bis NAV 2013 wäre diese Änderung bei 0 in dem Feld übrigens noch problemlos machbar, aber die Schemasynchronisierung ab R2 bringt viele neue Stolperfallen.

Object-Manager habe ich keinen.
Wie sieht es denn mit der Idee aus, die jeweilige Tabelle als Text zu exportieren, den Datentyp im Text-Export-File von Integer auf BigInteger zu ändern und das Text-File dann wieder importiere? Kann ja eigentlich nix passieren, wenn ich eine Sicherung der Tabelle mache; allerdings ist das eine Tabelle meines Chefs. Da will ich kein unnötiges Risiko eingehen.
Richtige Sicherungen sind eigentlich vorhanden, aber ich habe immer viel "Glück" damit. Und bevor alles in die Hose geht.

Auch der Import einer geänderten Tabelle erfordert eine erneute Schemasynchronisation, und Änderungen am Feldtyp bedeuten ab NAV 2013 R2 potenziell immer Datenverlust in dem Feld.
Steht im FAQ Artikel als "Destruktive Änderungen" bzw. hier bei MSDN Synchronizing Table Schemas für NAV 2015, der Abschnitt ab "Handling Destructive Changes With Table Schema Synchronization" trifft bei NAV 2013 R2 genauso zu.

Da gibt es einen Sicherheitsmechanismus den man deaktivieren kann, unter Extras->Optionen findet man einen Listeneintrag namens Datenverlust durch Tabellenänderungen verhindern. Den habe ich jetzt auf Nein gesetzt, weil die Daten in der zu ändernden Spalte ohnehin schon in einer tmp-Spalte gesichert wurden und ich mal davon ausgehe, dass der mögliche Datenverlust nur beim Ändern selbst Auswirkung zeigen wird.
So konnte ich den Datentyp ändern, habe die Daten zurück ins richtige Feld (Spalte) kopiert und jetzt sieht es gut aus.
Ich danke Dir vielmals für Deine Hilfestellung.

Viele Grüße
Kai

Hallo,

wenn dein Biginteger- Feld aber Bestandteil des Primärschlüssels ist, kickt aber alle Einträge weg, die dann doppelt wären, im Zweifel alle bis auf einen. Was bei einer Postentabelle schon sehr gravierende Auswirkungen haben kann.

Deshalb sehr sehr vorsichtig mit dieser Option umgehen.

Gruß Fiddi

Da gibt es einen Sicherheitsmechanismus den man deaktivieren kann, unter Extras->Optionen findet man einen Listeneintrag namens Datenverlust durch Tabellenänderungen verhindern.

Natürlich, das steht auch alles in meinem FAQ-Artikel bzw. ist der hier erwähnte Schalter. Der gilt aber für die gesamte Datenbank und nicht nur für dein Feld und ist in Echtsystemen hochriskant, da darf in der Entwicklung sonst niemand dran arbeiten bis der wieder umgestellt ist .