Dynamics AX Blog - Microsoft Dynamics AX (Axapta) - Seite 50

In Dynamics AX 4.0 haben sich in der Klasse SysMailerAddressField in Methode appendAddress einige Fehler eingeschlichen. Diese Fehler treten immer dann auf, wenn man per SysMailer Mails an mehr als einen Empfänger versenden möchte bzw. zusätzlich zur Empfängeradresse auch Empfängernamen angibt.

Hier wird bisweilen das Mail entweder nur an die zuletzt hinzugefügte Mail-Adresse versandt oder aber die send-Methode des SysMailers verweigert ganz ihren Dienst, wenn man Empfängernamen angibt.

Nachstehend der - aus meiner Sicht - korrekte Code:

// Add item to the collection
void appendAddress(str addr, str name='')
{
    str address;
    str addresses;

    if (prmisdefault(name))
    {
        address = addr;
    }
    else
    {
        address = name + ' <' + addr + '>';
    }

    addresses = this.get();

    if (strlen(addresses) > 0)
    {
        address = addresses + ',' + address;
    }

    this.set(address);

    addressCount++;
}

Aufgefallen sind mir die Fehler bislang bei Version 4.0 bis inkl. SP2.

Anbei ein Beispiel wie so mancher Report per Code ausgeführt werden kann, und dem Report dabei gleichzeitig ganz bestimmte Datensätze per Query übergeben werden können.

static void PrintCustCollectionLetterJour()
{
    CustCollectionLetterJour    CustCollectionLetterJour;
    query                       query;
    args                        args = new args();
    reportRun                   reportRun;
    ;

    select firstonly CustCollectionLetterJour;  // Irgendein Datensatz

    // Query aufbauen (mit obigen Datensatz)
    query = new query();
    query.addDataSource(tableNum(CustCollectionLetterJour));

    SysQuery::findOrCreateRange(query.dataSourceTable(TableNum(CustCollectionLetterJour)),
        fieldNum(CustCollectionLetterJour, CollectionLetterNum)).value(CustCollectionLetterJour.CollectionLetterNum);
    SysQuery::findOrCreateRange(query.dataSourceTable(TableNum(CustCollectionLetterJour)),
        fieldNum(CustCollectionLetterJour, AccountNum)).value(CustCollectionLetterJour.AccountNum);

    // Den Query dem Report übergeben
    args.name(reportstr('CustCollectionJour'));

    reportRun = classFactory.reportRunClass(args);

    reportRun.query().interactive(false);
    reportRun.report().interactive(false);
    reportRun.query(query);

    reportRun.init();

    reportRun.run();
}

Um aus AX4 auf eine externe Datenbank zugreifen zu können, kann man sich der Klasse CCADOConnection bedienen, nachstehend findet Ihr zwei Beispiele wie diese verwendet werden kann.

Aufruf über DSN

Aufruf ohne DSN

Es gibt vier verschiedene Dateien, in welchen serverseitig Informationen zu Labels gespeichert werden:

Bei den Datetypen, ald, alc und ali existiert pro Sprache und Labelfile jeweils eine Datei im AX-Applikationsverzeichnis (z.b. axSYSde-at wobei SYS für die Labeldatei und de-at für die jeweilige Sprache steht).

Bei den alt-Dateien existiert lediglich pro Sprache eine eigene Datei (z.b. axap*.alt wobei * für die jeweilige Sprache steht).

Einige Labels werden allerdings clientseitig im bin-Verzeichnis gespeichert. Dies sind z.b. jene des Menüs (Datei - Bearbeiten - Werkzeuge ...). Hier gibt es eigene Dateitypen:

Bei beiden Dateitypen existiert pro verwendeter Sprache jeweils eine Datei.

Da die Dateien clientseitig installiert sind, kann rein theoretisch jeder Client zumindest diese Texte anpassen, ob das Sinn macht bleibt dahingestellt. Außerdem besteht die Gefahr die Datei, durch Tippfehler oder wenn man die ktd-Datei im falschen Zeichensatz bearbeitet, zu zerstören. Dann ist der Client nicht mehr startbar!

In dieser ktd-datei werden übrigens auch einige andere Dinge gesteuert. Zum Beispiel liefert in einem deutschen AX die Abfrage

if("a" == "ä")

immmer true zurück. Grund hierfür ist die nachstehende Passage im zur deutschen Sprache gehörigen axsysde-at.ktd

>#97
>TC_COLSEQ
>Definition of collating sequence mapping
>This table is used when sorting letters and strings
>First line is the letters to be mapped
>Second line is the corresponding letter to map to
AàáâãäÀÁÂÃÄBCçÇDEèéêëÈÉÊËFGHIìíîïÌÍÎÏJKLMNñÑOòóôõöÒÓÔÕÖPQRSTUùúûüÙÚÛÜVWXYýÝZæøåÆØÅ
aaaaaaaaaaabcccdeeeeeeeeefghiiiiiiiiijklmnnnooooooooooopqrstuuuuuuuuuvwxyyyz~¦Ç~¦Ç

Um einen Report per X++ aufzurufen, und dabei eine bestimmte Methode des Reports anzusprechen kann man reportRun.owner() benutzen. Zwar steht hierbei IntelliSense nicht zur Verfügung, aber ich denke das ist zu verschmerzen.

Ich habe schon seit einiger Zeit das Buch Inside Microsoft Dynamics AX 4.0 auf meinem Schreibtisch liegen und verwende es immer wieder um kurz etwas nachzuschlagen. Und so manche Funktion bzw. Funktionsweise habe ich nur in diesem Buch erklärt bekommen, deshalb kann ich - obwohl ich leider noch nicht dazugekommen bin es komplett zu lesen - dieses Buch nur empfehlen.

Und das Beste daran: bei mfp's two cents habe ich folgenden Link gefunden:

http://download.microsoft.com/down...2579eBook.pdf

Über diesen kann man sich das komplette Buch als PDF herunterladen. Kostenlos!

Wem allerdings - so wie mir - die gebundene Variante lieber ist, kann sich das Buch natürlich gerne bei Amazon kaufen ;-)

Nachdem wir AX-Entwickler in der Version 4.0 leider der Möglichkeit des Sperrens und Entsperrens von Objekten beraubt wurden, habe ich in letzter Zeit vermehrt Zeit investieren müssen, um die in dieser Version integrierte Versionskontrolle (Microsoft Visual SourceSafe) an Stelle dessen zu verwenden.

Leider mit der - mittlerweile auch von Microsoft selbst bestätigten - Erkenntnis, daß bei aktivierter Versionskontrolle pro Applikation und AOS nur ein Entwickler unterstützt wird :-(

D.h. besteht die Notwendigkeit, daß mehrere Entwickler gleichzeitig an einer Applikation entwickeln, die Versionskontrolle in eigenem Interesse deaktiviert werden muß. Ansonsten kann es zu Verlust von Programmzeilen kommen!

Wozu ein einzelner Entwickler allerdings ein "schweres" Versionskontroll-System verwenden soll, ist mir persönlich allerdings schleierhaft.

Übrigens: Laut Microsoft soll in Dynamics AX 2009 dieser Mißstand behoben sein. Ich bin gespannt...