---
title: "C/AL-Besonderheiten und Codeanalyse | NAVtoBC.de"
description: "C/AL verstehen: Trigger, FlowFields, Objekte, Transaktionen und dynamische Abhängigkeiten. Analyse auf Basis von TXT-Objektexporten."
url: https://navtobc.de/de/cal-besonderheiten
language: de
---

# C/AL-Besonderheiten und Codeanalyse

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.

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

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

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

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

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

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

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

****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](https://navtobc.de/de/kontakt?thema=nav-analyse)

**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](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-txt2al-tool)
- [FOB/TXT: Objekte exportieren und importieren](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/cside/cside-import-objects)
- [.NET-Interop in NAV 2009 R2](https://www.microsoft.com/en-us/dynamics-365/blog/no-audience/2010/10/27/net-interoperability-in-nav-2009-r2/)
- [Events in C/AL seit NAV 2016](https://www.microsoft.com/en-us/dynamics-365/blog/business-leader/2015/10/15/integration-events-in-microsoft-dynamics-nav-2016/)
- [C/AL-Funktionen, Variablen und VALIDATE](https://www.microsoft.com/en-us/dynamics-365/blog/no-audience/2012/12/03/writing-unit-tests-in-cal/)
- [FlowFields in NAV 2018](https://learn.microsoft.com/en-us/previous-versions/dynamicsnav-2018-developer/FlowFields)
- [TXT-Objekte, Metadaten und Standardvergleich](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/comparing-and-merging-application-object-source-files)
- [TryFunctions und Fehlerbehandlung in C/AL](https://www.microsoft.com/en-us/dynamics-365/blog/business-leader/2015/10/28/nav-design-pattern-tryfunction-net-exception-handling-in-cal/)
- [SingleInstance, Arbeitsdatum und Seiteneffekte](https://www.microsoft.com/en-us/dynamics-365/blog/it-professional/2015/10/19/test-isolation-in-the-application-test-automation-suite/)
- [Sprachvergleich: Optionen gibt es auch in AL](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/methods-auto/option/option-data-type)
- [CHANGECOMPANY und Triggerkontext (AL-Referenz)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/methods-auto/record/record-changecompany-method)
- [Permissions und indirekte Rechte (AL-Referenz)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/properties/devenv-permissions-property)

[So verbinden wir Codeanalyse und KI](https://navtobc.de/de/methoden)