Verwaltung von Datenbankschemaänderungen

Dieses Thema soll als Sammelthema dienen, um die Veränderungen für die Verwaltung von Datenbankschemaänderungen in der Client-Server-Kommunikation u.a. stichpunktartig strukturiert zusammenzufassen, denn übersichtlicher ist es ja nicht geworden .

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

Bei Fehlern kommen u.a. Meldungen: The Object Metadata does not exist. Bei normalen Tabellen diese erneut kompilieren, bei Systemtabellen siehe hier.
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

Optionen 1 und 3 erfordern dabei einen laufenden Dienst (Serverinstanz) für die Datenbank, Option 2 dagegen nicht.

SaveTable.png

ImportFob.png

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 .

MeldungnachImportmitValidation.png

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:

TestfeldSyncLater.png

Testfeld1.png

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.

Testfeld2.png

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…

SchemaFürAlleTabellen.png

SyncAllTables.png

SyncAllTables2.png

…oder weiterhin via PowerShell durchzuführen, das geht entweder mit GUI-Unterstützung im PowerShell ISE…

SyncNavTenant.jpg

SyncNavTenant2.jpg

SyncNavTenant3.jpg

SyncAll3.png

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:

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).

SyncNavTenant4.jpg

SyncNavTenant5.jpg

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 "ForceSync" 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).

AbsturzClientBeimStart.png

Wenn man Glück hat, kommt im laufenden Client eine Fehlermeldung wie diese, wenn nicht, stürzt der Client ab.

MetadatenNichtsynchron.png

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

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

Nachtrag oben: Das Verfahren in NAV 2015.

Für Freunde der PowerShell bzw. solche, die es werden wollen oder müssen (in NAV 2013 R2 geht es mangels sicherer Alternativen nicht ohne) habe ich noch ein paar Bildchen eingefügt .

Ausschließlich für Dynamics 365 in Verbindung mit der von MS dort genutzen neuen optionalen Einstellung Shared Schema (pro NAV-Tabelle befinden sich hier die Daten aller Tenants und Mandanten in einer Tabelle auf dem SQL-Server) kommt ein weiteres Cmdlet: Sync-NAVTenantDatabase

Online noch nicht gelistet, aber schon in der PowerShell-Hilfe bedacht.

The shared schema feature is for use in conjunction only with Microsoft hosted offerings in Dynamics 365, is unsupported in Dynamics NAV, and may not be used outside Dynamics 365.

Beschreibung
Use the Sync-NAVTenantDatabase cmdlet to synchronize the database schema in a tenant database with the schema in the application database. Also, the Dynamics NAV Server instance must be configured for multitenancy. The application database contains tables that define the application. The tenant database must contain the SQL Server tables that the application requires.

Falls eine der obigen Methoden zur Komplettsynchronisation nicht angewandt wurden, stürzt der NAV 2015-Client beim Start sofort ab.

Das wurde mittlerweile behoben, eine aktuelle NAV 2018 z.B. startet zwar in einem solchen Fall auch nicht, liefert aber nunmehr einen brauchbaren Hinweis zur Abhilfe.

SchemasyncErforderlich.png

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

Falls sync-navtenant auf eine Sperre läuft:

The operation could not complete because a record was locked by another user. Please retry the activity.

Hier ein Workaround: http://www.dynamicsblog.at/sync-navtena ... -activity/

Hallo, ich versuche eine Rolle zu basteln, die nicht "SUPER" ist, aber trotzdem die Berechtigung eine Schema Synch. durchzuführen. Welche Tabellen muss denn diese Rolle enthalten (NAV 2018).

Gruß

Mathes

Bei Breaking Changes innerhalb der (eigenen) App: Upgrading an App by Using ForceSync

Bei der Entwicklung optionalen Schalter schemaUpdateMode in launch.json beachten, ForceSync erhält die Felddaten wenn machbar, Recreate löscht alle Feldinhalte in Tabellen der App . Die Vorgabe Synchronize erlaubt u.a. keine Feldverlängerungen.
Learn: Retaining table data after publishing

Business Central 2021 wave 2 (BC19) new features: Force sync of customer-specific extensions in online environments (ForceSync mode in Production Environment)

SchemaUpdateMode in AL in launch.json in D365 BC