Dynamics AX Blog - Dynamics AX 2012 - Beiträge von 2010 - Seite 2

Momentan angezeigt werden nur Beiträge, welche für die Dynamics AX-Version »Dynamics AX 2012« relevant sind. Filter entfernen

RSS-Feed dieser Version
Momentan angezeigt werden nur Beiträge von »2010«.

Feldwert eines aufrufenden Objektes ermitteln

In vielen Objekten sieht man Kontrukte wie das folgende, die dazu dienen, einen Wert aus dem aufrufenden Datensatz zu ermitteln.

if (element.args() && element.args().record())
{
    switch (element.args().dataset())
    {
        case tablenum(PurchLine)    :
            itemIdCaller = element.args().record().(fieldNum(purchLine, ItemId));
            break;
        case tablenum(SalesLine)    :
            itemIdCaller = element.args().record().(fieldNum(SalesLine, ItemId));
            break;
        case tablenum(SalesQuotationLine)    :
            itemIdCaller = element.args().record().(fieldNum(SalesQuotationLine, ItemId));
            break;
    }
}

Einfacher geht’s mit unten dem stehenden Stückchen Code! Der grosse Vorteil von diesem ist, daß wann immer man das Objekt von einem Datensatz aus aufruft, der ein Feld namens itemId enthält, die Logik abgearbeitet wird ohne daß man jede Tabelle einzeln im switch-Statement berücksichtigen muss.


 
 

Eine von RunBasebatch abgeleitete Klasse ist nicht im Stapel lauffähig

Vor kurzem hatte ich die Aufgabenstellung, eine Klasse die bereits von RunBase abgeleitet worden war, stapelfähig zu gestalten. So weit so einfach, dachte ich mir und habe in der ClassDeclaration der Klasse extends runBase durch extends runBaseBatch ersetzt. Ich hatte danach zwar den entsprechenden Register im Dialog, die Klasse wurde aber dennoch immer sofort ausgeführt :-(

Nach etwas herumprobieren hatte ich schlussendlich in der Methode getFromDialog den Fehler entdeckt: Diese war so programmiert, daß sie per return true immer true retouniert, das runBaseBatch-Framework benötigt an dieser Stelle allerdings ein return super().

Kleine Ursache, grosse Wirkung.


 
 

Notizen zur RecId

Die RecId ist die mehr oder weniger eindeutige Kennung eines Datensatzes in Dynamics AX. Mehr oder weniger deshalb, weil es auf die verwendete Version von Dynamics AX bzw. Axapta ankommt:

Version Bemerkung
3.0 RecId pro Mandant eindeutig (über alle Tabellen)
4.0 RecId pro Tabelle eindeutig (über alle Mandanten)
D.h. die selbe RecId kann in zwei oder mehreren Tabellen vorkommen, das ist auch der Grund, warum ein Feld einer Tabelle vom Typ RefRecId als EDT mit einer Relation abgebildet werden muss!
2009 Wie bei Version 4.0
2012 Wie bei Version 4.0

 
 

Unterschied zwischen update und doUpdate u.ä.

Mir persönlich dreht sich ja immer der Magen um, wenn ich in einer Produktivumgebung einen Stückchen Code mit doUpdate() oder Konsorten entdecke, trotzdem verwende ich solcherart Methoden auch gerne für den einen oder anderen Aktualisierungsjob. Wer den Unterschied zwischen dem Aufruf von update() und doUpdate() nicht kennt, kann diesen in der MSDN nachlesen...oder aber auch in der nachstehenden Tabelle.

Methode Bemerkung
insert vs. doInsert Bei Verwendung von doInsert wird die insert-Methode der Tabelle nicht aufgerufen
delete vs. doDelete Bei Verwendung von doDelete wird eine überschriebene delete-Methode der Tabelle nicht aufgerufen, sondern nur die delete-Methode des xRecord. D.h. DeleteActions werden dennoch ausgeführt
update vs. doUpdate Bei Verwendung von doUpdate wird die update-Methode der Tabelle nicht aufgerufen

 


 
 
Seiten « 1 2 

 

 
 
 
Beiträge des aktuellen Monats
Juni 2010
MoDiMiDoFrSaSo
 123456
78910111213
14151617181920
21222324252627
282930 
© 2006-2026 Heinz Schweda | Impressum | Kontakt | English version | Mobile Version
Diese Webseite verwendet Cookies, um Benutzern einen besseren Service anzubieten. Wenn Sie weiterhin auf der Seite bleiben, stimmen Sie der Verwendung von Cookies zu.  Mehr dazu