Schemaänderung bedeutet Veränderungen an einer Tabellenstruktur (Felder, Schlüssel), entweder manuell oder durch Tabellenimport.
Bitte Hinweise, Ergänzungen, Korrekturen dazuschreiben, ich baue die dann, wenn machbar, in die Stichpunkte ein.
Versionen bis NAV 2009 CC
- C/SIDE-Schemaänderung
- Kompilieren
- NAV-Server
- Schemaänderung Servertabellen (SQL, Native) (Mögliche Konflikte: Daten im gelöschten Feld, Feldlänge, Feldtypänderungen, Schlüsselverletzungen usw.)
NAV 2009 RTC - NAV 2013
Ab NAV 2009 RTC wird zur Laufzeit nicht mehr der C/AL-Code vom Client, sondern der beim Kompilieren erzeugte C#-Code in den Objektmetadaten bzw. DLLs ausgeführt, der sich im Servercache befindet.
- C/SIDE-Schemaänderung
- Kompilieren
- Object Change Listener
- Änderung Tabelle Object Metadata
- Update NAV-Servercache mit geänderten C#-Objekt-Metadaten
- SQL-Broker Service oder Polling via Tabelle "Object Tracking" (wird aktualisiert durch Löschen, Ändern und Einfügen in der "Object Metadata"-Tabelle)
- Schemaänderung SQL-Servertabellen
Ab NAV 2013 verfügbare Stapelverarbeitung für Erstellung der C#-Objekt-Metadaten: Serveranwendungsobjekte erstellen
In beiden Versionen ist das Kompilieren von Tabellen inklusive der vollständigen Konfliktprüfung auch dann noch möglich, wenn kein laufender Datenbankdienst vorhanden ist. Diese Möglichkeit besteht ab den Folgeversionen nicht mehr.
NAV 2013 R2
Auch im Single-Tenant-Betrieb ist die grundsätzliche Technologie für die Verwaltung von Multi-Tenancy-Datenbanken ab NAV 2013 R2 immer aktiv, da Microsoft hier nicht zweigleisig weiterentwickeln wollte. Das bedeutet, dass die ab dieser Version hinzukommenden Synchronisierungsprozesse beachtet werden müssen. Diese erfordern u.a. auch, dass der Netzwerkdienst ab dieser Version als "db_owner" definiert ist.
Nur in dieser Version befindet sich ein Schalter unter Optionen: "Datenverlust durch Tabellenveränderungen verhindern"
Bei = Ja (Vorgabe):
- C/SIDE Schemaänderung
- Kompilieren
- Object Change Listener
- Neu: Erst Anfrage beim SQL-Server ob Änderung möglich, d.h. ab dieser Version verwaltet der Server und nicht mehr C/SIDE den C/AL-Code. Wenn möglich, dann:
- Neu: Vergleich Tabelle Object Metadata mit Object Metadata Snapshot. Wenn Hash-Feld abweichend:
- Update NAV-Servercache mit geänderten C#-Objekt-Metadaten
- SQL-Broker Service oder Polling via Tabelle Object Tracking
- Neu: Die Synchronisation der Schemas erfolgt dabei durch 2 mögliche Methoden bei Single-Tenancy, 3 bei Multi-Tenancy. In C/SIDE kann die Synchronisation in dieser Version noch nicht gestartet werden.
- 1. PowerShell Sync-NAVTenant (sicheres Verfahren, wenn Timeout ausreichend groß, ggf. Tabellen in mehrere Importpakete aufteilen)
- 2. Clientstart oder jegliche Aktionen in laufenden Clients (unsicheres Verfahren, besonders bei größeren Änderungen)
- 3. Mounten eines neuen Tenant im Multi-Tenancy-Betrieb
- Schemaänderung SQL-Servertabellen.
Bei ("Datenverlust durch Tabellenveränderungen verhindern" = Nein) nur für Entwicklungs-/Testdatenbanken, nie in Echtsystemen anwenden .Mögliche Ursachen für Datenverlust siehe bei NAV 2015 unter "Destruktive Änderungen":
- C/SIDE Schemaänderung
- Kompilieren
- Object Change Listener
- Änderung Objekt-Metadaten (forciert, d.h. auch Änderungen, die zum Datenverlust führen würden, werden im Gegensatz zu NAV 2013/NAV 2009 angenommen. Da der Server ab dieser Version durch den neuen Schalter entkoppelt ist, wird das hier nicht geprüft. Bei vorhandener laufender Serverinstanz wird das Schema zum SQL-Server unmittelbar durchgedrückt. Das bedeutet bei destruktiven Änderungen sofortigen Datenverlust )
- Keine Schemaänderung bei fehlender Serverinstanz-> Windows-/Webclientstart nicht möglich wegen asynchroner Object Metadata - SQL-Tabellenschemas , Sync-NAVtenant erforderlich
Ab NAV 2015
In NAV 2015 wurde das Konzept, wie die Synchronisation verwaltet wird, umgearbeitet.
Neu: Die Synchronisation wird jetzt durch Aktivitäten in C/SIDE ausgelöst und kann vorübergehend zeitlich verschoben werden.
Aktivitäten sind
- 1. Arbeiten mit Schemaänderungen an einzelnen Tabellen
- entweder kompiliertes Speichern oder
- importieren von kompilierten Tabellen als Fob
- 2. Manuelles Synchronisieren aller Tabellen (Extras>Schema für alle Tabellen synchr.)
- 3. Upgradeprozesse (hierfür sind neue Codeunittypen nutzbar)
Hierbei werden bei jedem Speichern einer Tabelle oder jedem Fob-Importpaket mit Tabellen 3 Optionen angeboten:
- 1. Now - with validation sofortige Synchronisation mit Konfliktprüfung, d.h. wenn ohne Datenverlust möglich
- 2. Later Später, also vorerst keine Synchronisation und auch keine Konfliktprüfung
- 3. Force Erzwungene sofortige Synchronisation ohne Konfliktprüfung: Alle Konflikte werden ignoriert und das C/SIDE- Schema als SQL-Schema ohne Rücksicht auf Verluste durchgedrückt
Nach dem Import mit Option 1 erscheint diese Meldung, dort kann man die Synchronisation bei Bedarf noch unterbinden, falls diese dann doch erst später durchgeführt werden soll, bei Datenbanken mit hohem Aufkommen an Schemaänderungen, ggf. noch kombiniert mit hoher Mandanten- und/oder Tenantanzahl kann diese auch Stunden dauern. Ansonsten muss diese hier bestätigt werden. In einer Cronusdatenbank mit Feldänderungen im üblichen Rahmen dauert es meist nur ein paar Sekunden .
Beispiel 1: Anlegen eines neuen Feldes 50000 "Test" in C/SIDE, (kompiliert) speichern mit "Later", Änderung wird nicht mit SQL-Schema synchronisiert, Feld ist am SQL-Server nicht vorhanden:
Beispiel 2: Anlegen wie oben, aber (kompiliert) speichern mit "Now-with validation", Änderung wird mit SQL-Schema synchronisiert und das Feld ist dort sichtbar (unten angehängt), dieses wird dort multipliziert mit der Anzahl der Mandanten durchgeführt.
Unverändert nutzbar sind die PowerShell-Verfahren mit Sync-NAVTenant und Mounten eines neuen Tenant im Multi-Tenancy-Betrieb. Sync-NAVTenant hat ab dieser Version einen Mode-Schalter ( ForceSync (nicht mit dem ebenfalls verfügbaren -Force Parameter verwechseln, der die Abfrage unterbindet), Sync, CheckOnly) mit dem eingestellt wird, ob ggf. mit Datenverlust (-ForceSync) oder ohne synchronisiert (Sync) wird. Falls der nicht gesetzt wird, ist der Vorgabewert 'Sync'.
Es besteht also ab NAV 2015 mit "Later" die Möglichkeit, die Schemaänderungen in C/SIDE optional vorübergehend von den Schemaänderungen im SQL-Server zu entkoppeln und die Synchronisation zu einem späteren Zeitpunkt gezielt entweder manuell aus C/SIDE…
…oder weiterhin via PowerShell durchzuführen, das geht entweder mit GUI-Unterstützung im PowerShell ISE…
Importieren der Administration Tools im ISE (für NAV 2013 R2 \71\ statt \80\ im Pfad)
Out-null unterdrückt dabei die Ausgabe der Cmdletliste (die hat man im ISE rechts im Befehlsfenster zur Verfügung)
- Code: Alles auswählen
Import-Module C:\Programme\"Microsoft Dynamics NAV"\80\Service\NavAdminTool.ps1 -force | out-null
…oder rein zeichenbasiert in der Administration- bzw. Developer Shell (wenn man bei letzterer die Admintools mit dazu importiert).
Der Schalter "Datenverlust durch Tabellenveränderungen verhindern" der in NAV 2013 R2 unter Optionen vorhanden ist, wurde wieder entfernt.
Ablauf in NAV 2015:
- C/SIDE Schemaänderung
- Kompilieren
- Neu: Abfrage, wann und wie die Schemasynchronisation stattfinden soll (1. Now- with validation, 2. Later, 3. Force). Bei "Now - with validation":
- Object Change Listener
- Anfrage beim SQL-Server ob Änderung möglich (Server verwaltet den C/AL-Code für C/SIDE wegen der Multi-Tenancy-Erfordernisse). Wenn möglich, dann:
- Vergleich Tabelle Object Metadata mit Object Metadata Snapshot. Wenn Hash-Feld abweichend:
- Update NAV-Servercache mit geänderten C#-Objekt-Metadaten
- SQL-Broker Service oder Polling via Tabelle Object Tracking
- Schemaänderung SQL-Servertabellen.
Destruktive Änderungen, die bei der Option "Force" zum Datenverlust führen können (bzw. in NAV 2013 R2 bei "Datenverlust durch Tabellenveränderungen verhindern" = Nein)
- Löschen einer Tabelle
- Löschen eines Feldes
- Änderung am Feld "Data Type" (auch bei Wechsel Code <-> Text, Integer <-> BigInteger )
- Änderung am Feld "Class" (Normal, FlowField, Flowfilter)
- Änderung am Feld "SQL data type"
- Feldlängenverringerung
- Änderungen am Primärschlüssel (Entfernen von Feldern aus mehrfeldrigen Primärschlüsseln, die zu Eindeutigkeitsverletzungen führen)
- Neu: Änderung der Feld-ID das ist bis NAV 2013 noch möglich
Durch den Windows-/Webclientstart wie noch in NAV 2013 R2 findet keine Synchronisation mehr statt. Falls eine der obigen Methoden zur Komplettsynchronisation nicht angewandt wurden, stürzt der NAV 2015-Client beim Start sofort ab (Nachtrag April 2018: Der Absturz wird jetzt in den aktuellen Versionen abgefangen).
Wenn man Glück hat, kommt im laufenden Client eine Fehlermeldung wie diese, wenn nicht, stürzt der Client ab.
Stapelverarbeitung für C#-Objekt Metadaten
Serveranwendungsobjekte erstellen
Links:
NAV 2009
About Object Metadata and why I can't see object changes in RTC
Object Metadata update flow in Microsoft Dynamics NAV 2009
NAV 2013
Table Synchronization Paradigm in Microsoft Dynamics NAV 2013 R2
Synchronize Metadata please
NAV 2015
Synchronizing Table Schemas
Upgrade Codeunits
NAV 2016
Synchronizing Table Schemas
Upgrade Codeunits