--- id: navtobc-cal-besonderheiten type: knowledge-entry language: de updated: 2026-10-09 status: freigegeben --- # Wenig Code. Viel Wirkung. Übernommen von [NAVtoBC.de](), Quellenstand: 2026-10-09. DIE BESONDERHEITEN VON C/AL ## Wenig Code. Viel Wirkung. In Navision steckt Geschäftslogik nicht nur in Funktionen. Auch Feldeigenschaften, Trigger, Filter und der Ausführungskontext bestimmen, was tatsächlich passiert. Wer C/AL automatisiert analysiert, muss diese Zusammenhänge gemeinsam lesen. Hier sind die wesentlichen Besonderheiten für eine fundierte Analyse und Migrationsplanung. C/AL RICHTIG EINORDNEN ### Von Navision bis Business Central 14. **C/AL steht für Client/server Application Language.** Die Sprache wurde in Navision und Dynamics NAV eingesetzt und war noch in Business Central 14 (Spring 2019, On-Premises) verfügbar. Ab Business Central 15 wurde C/AL durch AL abgelöst. UNSERE ANALYSEBASIS ### TXT-Objektexporte. Wir lesen die als **TXT exportierten NAV-Objekte** mit C/AL-Code und Objekteigenschaften. **Native FOB-Dateien werden nicht direkt verarbeitet.** Liegen nur FOB-Dateien vor, werden die Objekte zunächst in eine geeignete NAV-Entwicklungsumgebung importiert und dort als TXT exportiert. Dafür sind ein passender Versionsstand und die erforderliche Entwicklerlizenz nötig. Eine umbenannte Dateiendung genügt nicht. EIN KLEINER UNTERSCHIED MIT FOLGEN ### Zuweisen oder validieren? Beide Zeilen setzen einen Wert im Record-Puffer. `VALIDATE` führt zusätzlich die Feldvalidierung einschließlich `OnValidate` aus. Dieser Trigger kann weitere Felder verändern, Geschäftslogik auslösen und selbst Datenbankänderungen vornehmen. Direkte Zuweisung ``` Customer.Name := 'Beispiel'; ``` Mit Feldvalidierung ``` Customer.VALIDATE(Name, 'Beispiel'); ``` ### Was bei der Analyse zusammengehört. Die Themen aufklappen und die technischen Details entdecken. 01 **Sprache & Werte** Pascal-Syntax, Code, Optionen und fachliche Datentypen \+ - **Pascal-geprägte Syntax:** `BEGIN … END`, `:=` für Zuweisungen sowie `//` und `{ … }` für Kommentare. Bezeichner und Schlüsselwörter unterscheiden nicht nach Groß- und Kleinschreibung. Variablen werden global im Objekt oder lokal in Funktionen und Triggern deklariert. `VAR`-Parameter können den Wert beim Aufrufer verändern. - **Code ist ein eigener Datentyp:** Er wandelt Text in Großbuchstaben um und entfernt führende und nachfolgende Leerzeichen. Die definierte Länge von `Code` und `Text` gehört zur Auswertung. Zeichenketten und Arrays werden ab Position 1 adressiert. - **Optionen haben eine Reihenfolge:** `OptionString` definiert die Mitglieder; ihre Zahlenwerte beginnen bei 0. Name, Position und übersetzte Beschriftung sind zu unterscheiden. Ein Umbau auf AL-Enums muss die vorhandenen Werte berücksichtigen. AL unterstützt weiterhin auch `Option`; die Umstellung auf Enums ist nicht automatisch zwingend. - **Fachliche Werte statt bloßer Zahlen:** `0D`, Abschlussdaten, `WORKDATE` und Datumsformeln haben eigene Bedeutung. Rundungsregeln sowie sprachabhängige Umwandlungen mit `FORMAT` und `EVALUATE` können Ergebnisse und Schnittstellen beeinflussen. **Für die Analyse:** Gleiche sichtbare Werte können technisch unterschiedlich behandelt werden. Datentyp, Länge, Sprache und Parameterübergabe gehören deshalb zum Befund. 02 **Objekte & Metadaten** Typ plus ID, Feldnummern und Eigenschaften \+ - **Objekte statt einzelner Quelldateien:** Je nach NAV-Version gehören Table, Page, Report, Codeunit, Query, XMLport und MenuSuite dazu; ältere Generationen kennen auch Form und Dataport. Eindeutig ist die Kombination aus **Objekttyp und ID** . Der Bereich 50000–99999 ist klassisch für Kundenanpassungen vorgesehen; Partnerbereiche und Nutzbarkeit hängen auch von der Lizenz ab. - **Eigenschaften tragen Geschäftslogik:** `TableRelation`, `CalcFormula`, `SourceTableView`, `RunObject` und `RunPageLink` erzeugen Beziehungen, Filter und Aufrufe außerhalb des eigentlichen C/AL-Codes. Feldnummern, Schlüssel, Report-DataItems und XMLport-Strukturen gehören ebenfalls zum Modell. - **Bezeichner sind keine Beschriftungen:** `CaptionML` und `OptionCaptionML` liefern mehrsprachige Anzeigen, etwa Deutsch und Englisch. Sie ersetzen weder Objekt- noch Feldidentitäten. Sprachstand und Zeichenkodierung des TXT-Exports müssen erhalten bleiben. **Für die Analyse:** Ein vollständiger Objektexport enthält mehr Wissen als herauskopierte Funktionen. Metadaten sind ein Teil des Programms. 03 **Trigger & Geschäftslogik** VALIDATE, RunTrigger und versteckte Folgeaktionen \+ - **Trigger und Funktionen:** C/AL bietet globale und lokale Funktionen. Daneben stehen Tabellen-Trigger wie `OnInsert`, `OnModify`, `OnDelete` und `OnRename`, Feld-Trigger wie `OnValidate` und `OnLookup` sowie Page- und Report-Trigger. Reihenfolge und Aufrufkontext sind entscheidend. - **Ein Parameter verändert den Ablauf:** Bei `INSERT`, `MODIFY` und `DELETE` steuert `RunTrigger`, ob der zugehörige Tabellen-Trigger ausgeführt wird. Ohne Angabe ist er `FALSE`. `MODIFY(TRUE)` führt `OnModify` aus, validiert aber nicht automatisch jedes Feld. Massenoperationen müssen gesondert betrachtet werden. - **Prüfen, übertragen und validieren unterscheiden sich:** `TESTFIELD` prüft einen Feldwert. `TRANSFERFIELDS` ordnet Werte über Feldnummern zu und führt keine `OnValidate`-Trigger aus. Eine direkte Feldzuweisung umgeht ebenfalls diese Feldvalidierung. - **Impliziter Kontext:** `Rec`, `xRec` und `WITH` beeinflussen, worauf sich ein Ausdruck bezieht. Lokale und globale Variablen haben unterschiedliche Gültigkeitsbereiche. Globale Variablen können Zustand innerhalb einer Objektinstanz erhalten; `SingleInstance`-Codeunits teilen ihre Instanz innerhalb einer Sitzung. **Für die Analyse:** Ein Funktionsname allein erklärt den Ablauf nicht. Auch Trigger-Schalter, Variablenkontext und ausgelöste Folgeaktionen müssen nachvollzogen werden. 04 **Record-Zustand & Berechnungen** Filter, FlowFields, temporäre Daten und Mandanten \+ - **Records merken sich mehr als Feldwerte:** Filter, Filtergruppen, Schlüssel und aktueller Datensatz beeinflussen Zugriffe. `SETRANGE`, `SETFILTER`, `FILTERGROUP`, `RESET`, `FINDSET`, `FINDFIRST` und `NEXT` müssen im Zusammenhang gelesen werden. `GET` verwendet den Primärschlüssel und ignoriert gewöhnliche Filter; Sicherheitsfilter sind gesondert zu berücksichtigen. - **FlowField ist nicht FlowFilter:** Ein FlowField speichert sein berechnetes Ergebnis nicht dauerhaft in der Tabelle. `CalcFormula` beschreibt die Berechnung, etwa eine Summe oder einen Lookup. `CALCFIELDS` berechnet den Wert; je nach Einbindung übernimmt dies auch die Oberfläche. Ein FlowFilter liefert Filterbedingungen für solche Berechnungen und berechnet selbst keinen Ergebniswert. - **Gleiche Tabelle, anderer Kontext:** Temporäre Record-Variablen verarbeiten Daten im Speicher. `CHANGECOMPANY` ändert den Mandanten des Datenzugriffs; Trigger laufen weiterhin im aktuellen Mandantenkontext. `DataPerCompany` unterscheidet mandantenbezogene und gemeinsame Tabellen. **Für die Analyse:** Tabellenname und Feldwert reichen nicht aus. Filter, Berechnungsdefinition, temporärer Zustand und Mandant bestimmen die Aussage. 05 **Dynamische Abhängigkeiten & Events** RecordRef, FieldRef, Aufrufe und Subscriber \+ - **Wiederverwendung ohne Klassenmodell:** C/AL bietet keine Sprach-Namespaces und keine nativen Interface-Definitionen. Ein eigenes Klassenmodell mit Vererbung gehört ebenfalls nicht zur Sprache. Codeunits stellen globale Funktionen bereit; `CODEUNIT.RUN` startet deren `OnRun`-Trigger. Referenzen können über Namen, deklarierte Objektsubtypen oder Nummern aufgelöst werden. - **Ziele können erst zur Laufzeit feststehen:** `RecordRef`, `FieldRef`, `Variant` und variabel übergebene Objekt-IDs erlauben generische Verarbeitung. Auch Konfigurationstabellen können festlegen, welcher Code tatsächlich aufgerufen wird. - **Events sind bereits Teil von C/AL:** Seit NAV 2016 können Publisher und Subscriber zusätzliche Aufrufbeziehungen schaffen. Die Analyse muss diese Bindungen berücksichtigen; eine Suche nach direkten Funktionsaufrufen erfasst sie nicht vollständig. **Für die Analyse:** Statisch belegte Abhängigkeiten und erst mit Konfiguration oder Laufzeitwissen auflösbare Beziehungen werden getrennt ausgewiesen. 06 **Transaktionen & SQL** COMMIT, Fehlerbehandlung, Schlüssel und Sperren \+ - **Transaktionen laufen teilweise implizit:** C/AL eröffnet und beendet Datenbanktransaktionen automatisch. `COMMIT` setzt eine ausdrückliche Grenze. Ein späterer Fehler nimmt bereits bestätigte Änderungen nicht zurück. - **Fehlerbehandlung ist Teil der Logik:** Rückgabewerte von Datenbankfunktionen, der ausgewertete Boolean-Rückgabewert von `CODEUNIT.RUN` und `TryFunction` verändern den Fehler- und Transaktionsablauf. Datenbankänderungen innerhalb einer TryFunction werden bei einem abgefangenen Fehler nicht automatisch zurückgerollt; zulässige Schreibzugriffe hängen von Version und Serverkonfiguration ab. - **C/AL beeinflusst SQL, ohne SQL zu zeigen:** `SETCURRENTKEY`, Filter, `LOCKTABLE`, `FINDSET`, Schlüssel und SIFT-Aggregate wirken auf Zugriffe und Sperrverhalten. Ein gesetzter Schlüssel garantiert keinen bestimmten SQL-Ausführungsplan. Auffällige Muster liefern Ansatzpunkte; ihre tatsächliche Performance wird gemessen. **Für die Analyse:** Datenkonsistenz und Performance lassen sich nur mit Transaktionsgrenzen, Fehlerpfaden und dem konkreten Datenbankbetrieb bewerten. 07 **Historie & Standardvergleich** TXT-Format, Version List, Länderstände und Anpassungen \+ - **Ein eigenes, dokumentiertes Exportformat:** C/SIDE verwaltet Objekte in der Datenbank und exportiert sie als FOB oder TXT. TXT enthält Quellcode und Metadaten wie Version List, Datum, Uhrzeit und Modified-Flag. Solche Exporte lassen sich mit Git verwalten; technische Metadaten können Vergleiche jedoch mit zusätzlichen Änderungen füllen. Microsoft stellt selbst Vergleichs- und Konvertierungswerkzeuge bereit. - **Anpassungen können im Standard stecken:** In klassischen NAV-Projekten wurde Microsoft-Code häufig direkt geändert. Die `Version List` ist ein Hinweis, kein vollständiger Änderungsnachweis. Belastbar wird die Einordnung durch einen Vergleich mit dem passenden unveränderten Ausgangsstand und vorhandener Projektdokumentation. - **Die richtige Basis zählt:** NAV-Version, Build beziehungsweise kumulatives Update, Länderstand und Partnerlösungen müssen zusammenpassen. Deutsche, österreichische oder schweizerische Lokalisierungen können andere Standardobjekte und fachliche Regeln enthalten. **Für die Analyse:** Erst der passende Vergleichsstand zeigt, welche Logik zum Standard, zur Lokalisierung, zu einem Add-on oder zur individuellen Anpassung gehört. 08 **Laufzeit, Rechte & Schnittstellen** Clientgenerationen, Berechtigungen und externe Einstiegspunkte \+ - **Die NAV-Generation verändert die Umgebung:** Classic Client, RoleTailored Client ab NAV 2009, Forms und Pages sowie Dataports und XMLports gehören zu unterschiedlichen Entwicklungsständen. .NET-Interop wurde bereits mit **NAV 2009 R2** eingeführt. Automation/COM, .NET-Komponenten und Client- beziehungsweise Serverausführung müssen versionsbezogen betrachtet werden. - **Rechte sind nur teilweise im Export sichtbar:** Die Objekteigenschaft `Permissions` gehört zum Quellbestand. Zugewiesene Permission Sets, Benutzerrechte, Sicherheitsfilter und Lizenzumfang müssen zusätzlich erfasst werden. Indirekte Berechtigungen können beeinflussen, über welchen Ablauf Daten geändert werden dürfen. - **Nutzung beginnt auch außerhalb des Codes:** Aufgabenwarteschlangen, veröffentlichte Webservices, Dateipfade, externe Komponenten und angebundene SQL-, EDI- oder Shopsysteme können Abläufe starten oder steuern. `GUIALLOWED` und clientabhängige Funktionen sind für Hintergrundläufe relevant. Fehlende statische Aufrufe beweisen deshalb keine Nichtnutzung. **Für die Analyse:** Der TXT-Export wird mit freigegebener Konfiguration, Schnittstellenwissen und geeigneten Nutzungsnachweisen ergänzt. Offene Abhängigkeiten werden gezielt mit IT und Fachbereichen geklärt. WAS SIE DAVON HABEN ### Geschäftsregeln verstehen. Migration fundiert planen. Eine belastbare Analyse verbindet C/AL-Code, Objektmetadaten und den tatsächlichen Betrieb. So werden Regeln, Abhängigkeiten und offene Fragen nachvollziehbar – als Grundlage für Business Central-Standard, geeignete Module und gezielte AL-Entwicklung. [C/AL-Analyse anfragen →]() Fachliche Quellen & Einordnung \+ Geprüft am 09.10.2026 anhand der Microsoft-Dokumentation. Die Übersicht bündelt die wesentlichen Besonderheiten für die Analyse; Details hängen von NAV-Version, Objektstand und Betriebsumgebung ab. - [C/AL bis Business Central 14 und TXT-Objektexporte]() - [FOB/TXT: Objekte exportieren und importieren]() - [.NET-Interop in NAV 2009 R2]() - [Events in C/AL seit NAV 2016]() - [C/AL-Funktionen, Variablen und VALIDATE]() - [FlowFields in NAV 2018]() - [TXT-Objekte, Metadaten und Standardvergleich]() - [TryFunctions und Fehlerbehandlung in C/AL]() - [SingleInstance, Arbeitsdatum und Seiteneffekte]() - [Sprachvergleich: Optionen gibt es auch in AL]() - [CHANGECOMPANY und Triggerkontext (AL-Referenz)]() - [Permissions und indirekte Rechte (AL-Referenz)]() [So verbinden wir Codeanalyse und KI →]() --- [Datensatz (JSON)]() · [Katalog]()