Microsoft Dynamics AX: So funktionieren vererbte Tabellen

Microsoft führte das Thema der „vererbten Tabellen“ mit der Version AX2012 ein. Als Beispiel untersuchen wir in diesem Beitrag die Tabelle EcoResProduct.

Der Programmierer steuert die Vererbung von Tabellen durch die Eigenschaft „SupportInheritance“ in den Eigenschaften der Tabelle:

Microsoft Dynamics AX: vererbte Tabellen

Wird eine Tabelle neu angelegt, muss diese Eigenschaft gesetzt werden, bevor neue Felder dieser Tabelle hinzugefügt werden. Nachdem neue Felder angelegt worden sind, wird folgende Fehlermeldung angezeigt:

„Die Eigenschaft für Vererbungsunterstützung kann für eine Tabelle mit vorhandenen Feldern nicht auf ‚Ja‘ festgelegt werden“.

In unserem Beispiel wollen wir unterscheiden, ob sich bereits Daten in der Tabelle befinden oder ob die Felder gelöscht und neu angelegt werden können.

Ein Bild der Tabelle und den davon abhängigen, abgeleiteten Tabellen kann man unter dem Punkt „Typhierachiebrowser“ in der Entwicklungsumgebung abrufen.

Hier erscheint grafisch die Tabelle mit ihren Feldern und Methoden. Dies gilt ebenfalls für die Felder und Methoden, welche durch die abgeleiteten Tabellen hinzugekommen sind.

Für eine größere Ansicht bitte in das Bild klicken.

Das abgebildete Beispiel zeigt, dass die Tabelle EcoResProduct zweimal abgeleitet ist:

einmal zu EcoResDistinctProduct
und einmal zu EcoResProductMaster

Die EcoResProductMaster besitzt neue Felder und Tabellen, unter anderem die Felder RetailColorGroupId, RetailSizeGroupID und RetailStyleGroupId.

Vererbte Tabellen: die Methoden orig() und data()

Die vererbten Tabellen bringen einige Besonderheiten mit, die im Umgang mit ihnen beachtet werden sollten. Hier untersuchen wir die Methoden orig() und data().

Als Grundlage der Untersuchung dient ein AX2012 R3 Contoso Image mit dem Mandanten „demf“, welche zur besseren Lesbarkeit auf eine deutsche Oberfläche umgestellt wurde. Kernel und Application Version ist 6.3.2000.326.

Wie der Tabellen-Browser zeigt, sind Daten in der Tabelle vorhanden:

Für eine größere Ansicht bitte in das Bild klicken.

Es wird folgender Job geschrieben, um das Verhalten von AX mit vererbten Tabellen zu verdeutlichen:

static void RD_OrigAndData(Args _args)

{

EcoResProductMaster ecoResProductMaster;

EcoResProductMaster getDateRecord;

;

select firstOnly ecoResProductMaster where ecoResProductMaster.DisplayProductNumber == "0140";

info(strFmt("%1", ecoResProductMaster.RetailColorGroupId));

info(strFmt("%1", ecoResProductMaster.orig().RetailColorGroupId));

info(strFmt("%1", ecoResProductMaster.DisplayProductNumber));

info(strFmt("%1", ecoResProductMaster.orig().DisplayProductNumber));

getDateRecord = ecoResProductMaster.data();

info(strFmt("%1", ecoResProductMaster.RetailColorGroupId));

info(strFmt("%1", getDateRecord.RetailColorGroupId));

info(strFmt("%1", ecoResProductMaster.DisplayProductNumber));

info(strFmt("%1", getDateRecord.DisplayProductNumber));

}

Dabei wird ein Feld aus der vererbten Tabelle und ein Feld aus der Parenttable ausgegeben – jeweils einmal aus dem aktuellen Datensatz und einmal über die Funktion orig().

Im zweiten Teil des Jobs wird der Datensatz mittels der Funktion data() übergeben und wieder die Daten ausgegeben. Das Ergebnis lautet:

Wie zu sehen ist, wird über die Funktionen orig() und data() im besten Fall ein leeres Feld zurückgegeben und im schlimmsten Fall etwas „Kryptisches“. Diese Funktionen sollten also bei vererbten Tabellen nicht benutzt werden.

Mitgewirkt an der Erstellung dieses Artikels hat Yasin Yücel. Weitere Coding-Tipps für Microsoft Dynamics AX finden Sie im Digital-Dialog von Rödl & Partner.

Sie haben Fragen zu der Dynamics-AX-Beratung von Rödl & Partner? Alexander Schünemann (Tel. +49 [621] 595 708 – 48) ist als Leiter Entwicklung gerne für Sie da.

zuletzt aktualisiert am 06.12.2016