Dynamics AX Blog - Beiträge von 2009

In Dynamixs AX stehen dem Entwickler zwei Methoden zur Verfügung, die zur Berechnung der Kalenderwoche dienen: weekOfYear und wkOfYr.

Der Unterschied zwischen den beiden ist, daß die Methode weekOfYear die Kalnderwoche nach amerikanischem Vorbild berechnet. Dieser Standard legt die erste Woche als jene fest, in die der 1. Januar fällt.

Für den deutschsprachigen Raum sollte die - der ISO 8601 entsprechenden - Methode wkOfYr verwendet werden. Nach dieser Norm ist die erste Woche jene, die den ersten Donnerstag des Jahres enthält.

Schon einmal einen Base Enum in Dynamics AX erstellt? Oder einen bestehenden erweitert?

Ja?! Dabei auch auf das folgende geachtet?

.) Das erste Element eines Base Enums sollte den Wert 0 aufweisen und dieser sollte "Undefiniert", "Kein", "Unbekannt" oder ähnlichem entsprechen. Vor allem wenn man den Base Enum später in Tabellen verwenden möchte, die bereits Daten enthalten.
Selbst wenn man davon ausgehen kann, daß man einen solchen undefinierten Zustand nicht benötigt, sollte man die 0 reserviert halten, sprich der erste "echte" Wert des Base Enums sollte 1 entsprechen.

Nachstehend Beispiele für den Zugriff auf die AX-Datenbank per SQL-Statement, diese Zugriffe müssen im übrigen immer serverseitig erfolgen (runOn-Property).

Beispiel für ein SELECT-Statement

public void run()
{
    Connection                      connection = new Connection();
    Statement                       stmt = connection.createStatement();
    sqlStatementExecutePermission   sqlStatementExecutePermission;
    str                             sqlStmt;
    resultSet                       resultSet;
    ;
    
    sqlStmt = "SELECT accountNum, name, creditMax FROM custTable;";
    
    sqlStatementExecutePermission = new SqlStatementExecutePermission(sqlStmt);
    sqlStatementExecutePermission.assert();     resultSet = stmt.executeQuery(sqlStmt);

    while (resultSet.next())
    {
        info(strFmt("%1 %2 %3", resultSet.getString(1), resultSet.getString(2), resultSet.getReal(3)));
    }
    CodeAccessPermission::revertAssert();
}

Übrigens: Wenn folgender Fehler beim Abfragen des resultSets auftritt, kann die Ursache ein ungültiges SQL-Statement sein!

Ein Datensatz in  () kann nicht ausgewählt werden.
Die SQL-Datenbank hat einen Fehler gemeldet.

Hinweis: Zu diesem Thema ist eine aktuellere Version verfügbar

Sollen in einem Formular nur bestimmte Felder zur Bearbeitung freigegeben sein, kann man die Eigenschaft allowEdit sämtlicher Felder der DataSource der Tabelle entsprechend umsetzen.

Einfacher geht’s mit folgendem Codebeispiel, welches in der init-Methode der DataSource eingebunden wurde und - im konkreten Fall in der Tabelle SalesLine - nur bei einem einzigen Feld die Bearbeitung erlaubt.

Getestet in AX 3.0
 

Kurzer Eintrag in eigener Sache:

Heute morgen habe ich eine weitere Microsoft Zertifizierungsprüfung - der genaue Titel lautete Microsoft Dynamics AX 2009 Trade & Logistics - erfolgreich abgelegt.

Ich kenne kein einziges AX-Projekt, in dem nicht zumindest einer der Berichte Auftragsbestätigung, Ausgangslieferschein oder Ausgangsrechnung angepasst worden sind. Und deshalb stolpere ich auch immer wieder über das selbe Problem: Man erweitert einen Bericht (Report) um einen PageFooter, der aber nicht auf jeder Seite angedruckt werden soll.

Daß man einen Mandanten/Unternehmen duplizieren kann, ist bekannt. Die Erfahrung der vergangenen Wochen hat mich in dem Zusammenhang folgendes gelehrt:

• Man sollte der einzige Benutzer im System sein,
• nur eine(!) aktive Client-Sitzung geöffnet haben und
• ausreichend Zeit für den Vorgang eingeplant haben, während der das System im exklusiven Zugriff verbleibt.

Um sicherzustellen, daß man der einzige Benutzer im System ist, sollte man alle anderen deaktivieren.

Außerdem sollte man vor dem Kopiervorgang ein Datenbank-Backup anlegen und nach der erfolgten Aktion den Quell- und Zielmandant hinsichltich doppelter Datensätze vergleichen. Hierfür kann man sich der Funktion "Anzahl der Datensätze" bedienen.