Dynamics AX Blog - Seite 36

In Dynamics AX 2012 verfügt das Query-Objekt nun über eine neue Methode addQueryFilter, mit dessen Hilfe man die Datenbank anweisen kann, Filterkriterien zur WHERE-Clause statt wie in bisherigen Versionen zur ON-Clause einer OUTER-JOIN-Verknüpfung hinzuzufügen. Dies wiederum bewirkt, daß keine "leeren" Datensätze verarbeitet werden.

Wer schon einmal eine Tabelle aufbauen musste, wo die einzelnen Datensätze über Datumsfelder nur für einen bestimmten Zeitraum gültig sind - ähnlich den Handelsvereinbarungen -, weiß wieviel Entwicklungsaufwand daintersteckt, wenn sichergestellt werden muss, daß sich die Gültigkeitsbereiche der einzelnen Datensätze nicht überschneiden.

Dynamics AX 2012 stellt hierfür eine neue Tabelleneigenschaft validTimeStateFieldType zur Verfügung, mit deren Hilfe sich Dynamics AX selbst um vieles kümmert.

Beim Anlegen einer solchen Tabelle muss nur auf die folgenden Punkte geachtet werden:

1. Eigenschaft ValidTimeStateFieldType der Tabelle auf Date oder UtcDateTime setzen. Dadurch erstellt AX zwei neue Felder ValidFrom und ValidTo in der Tabelle.
   
   
    
2. Man muss einen eindeutigen Index erstellen, der die entscheidenden Felder der Tabelle sowie die Felder ValidFrom und ValidTo enthält.
   
   
    
3. Bei diesem Index müssen bestimmte Eigenschaften gesetzt werden.
   
   

Ab diesem Zeitpunkt kümmert sich Dynamics AX vollständig um das Aktualisieren von nicht mehr gültigen Datensätzen und die entscheidenden Prüfungen beim Anlegen von neuen Datensätzen.

Aber auch das Selektieren des jeweils gültigen Datensatzes für ein bestimmtes Datum wird wesentlich erleichert. Dafür stellt Dynamics AX das Keyword validTimeState zur Verfügung.

Im folgenden sind einige Gedankennotizen zum Thema Datum und Uhrzeit in Dynamics AX notiert.

In allen mir bekannten Versionen von Dynamics AX bzw. Axapta gibt es die nachstehenden Funktionen:

Ab Dynamics AX 2009 stehen u.a. zusätzliche folgende Funktionen zur Verfügung: 

In allen bisherigen Dynamics AX-Versionen wird das Systemdatum und die Systemzeit von der Zeit des Clients initialisiert. Diese Werte kann sich der Benutzer - entsprechende Rechte vorausgesetzt - jederzeit selbst ändern (die Uhrzeit allerdings erst seit Dynamics AX 2009). Sie gelten aber nur für die aktuelle Sitzung und nur für diesen Benutzer.
 
Übrigens: Erhält man unter AX 2009 beim Starten eines AX-Clients die nachstehende Fehlermeldung, sollte man die Zeitzone des aktuellen Benutzers in den Benutzeroptionen prüfen.

Die Zeitzone des lokalen Comuters stimmt nicht mit den Einstellungen für die bevorzugte Zeitzone überein.

Wie startet man einen Bericht, bei dem eine von RunBaseReport abgeleitete Klasse vorgeschalten ist, per X++ und gibt diesem Bericht bereits den Query und die Druckeinstellungen vor?

Wer sich diese Frage schon einmal stellen musste, für den liefert dieser Blogbeitrag vielleicht einen Lösungsansatz:

static void setPrintJobSettingsQuery4ReportClass_II(Args _args)
{
    custReport          custReport = new custReport();
    printJobSettings    printJobSettings = new printJobSettings();
    ;
    custReport.makeReportRun();

    // Modify Query
    sysQuery::findOrCreateRange(custReport.reportRun().query().dataSourceTable(tableNum(custTable)), fieldNum(custTable, custGroup)).value(queryValue('10'));
    custReport.reportRun().query().interactive(false);
    // Create printJobSettings
    printJobSettings.setTarget(PrintMedium::File);
    printJobSettings.format(PrintFormat::PDF);
    printJobSettings.fileName(@"C:\Temp\CustTableReport.pdf");

    // Apply printJobSettings
    custReport.reportRun().printJobSettings(printJobsettings.packPrintJobSettings());
    custReport.reportRun().report().interactive(false);  // Disable default printer-dialog
    custReport.reportRun().run();
}

Obiger Code instanziiert ein Objekt der Klasse custReport, deren wesentliche Methoden wie folgt aussehen:

class CustReport extends runBaseReport
{
}

public identifiername lastValueElementName()
{
    identifiername ret;

    //ret = super();

    ret = reportStr(Cust);

    return ret;
}

static ClassDescription description()
{
    return "Custreport";
}

static void main(Args args)
{
    CustReport  CustReport;
    ;
    CustReport = new CustReport();
    if (CustReport.prompt())
    {
        CustReport.run();
    }
}

Wenn man in Dynamics AX (4.0 bzw. 2009) einmal in die Verlegenheit kommen sollte, prüfen zu müssen, ob es Tabellen mit doppelten RecIDs gibt, kann folgendes SQL-Script dabei behilflich sein:

Die Feldgruppe AutoReport einer Tabelle und deren Verwendung beim Drucken von Daten aus einem Formular heraus sollte wohl jedem Dynamics AX-Entwickler bekannt sein. Auf Basis dieser Standard-Funktionalität habe ich versucht, selbst einen Report per X++ auf Basis eines Query zu erstellen.

Das Ergebnis des obigen Codes ist ein sehr einfacher Report:

Um in einem Objekt auf das aufrufende Objekte zuzugreifen, habe ich anhand von einigen Zeilen Code ja schon demonstriert (siehe hier und hier). Dabei hatte ich aber immer ausser Acht gelassen, daß das aufrufende Objekt ja auch eine Klasse sein kann.

Nun also hier ein entsprechendes Beispiel:

if (element.args() && 
    element.args().caller() && 
    classidget(element.args().caller()) == classnum(nameOfClass )) 
{
    nameOfClass = element.args().caller();
    someValue = nameOfClass.someMethod();
}