Ms Dynamics AX

Script to recreate SqlDictionary records in AX 2009

2011-09-01T02:25:00.001+04:00

Here's a script that can recreate SqlDictionary records in AX 2009 for any field of (nonsystem) table - in case such record is missing for some reason while the field exists in the database. I used this script during an upgrade to AX 2009 last year. Some fields in the standard application got the same IDs as fields added during customizations and they had different base types, of course, and it seemed impossible to fix the situation using standard means. The script might be of interest to those who wants to know the relations between the SqlDictionary and the AOT.

#macrolib.DictField
// This type is used instead of Types::Int64 for fields of type
// RecId/RefRecId/createdTransactionId/modifiedTransactionId
#define.RecIdBaseType   (49)
// For nonsystem fields of type UtcDateTime an additional field is created
// that holds the actual time zone in which the value has been set
#define.TZIDsuffix      ('_TZID')          

SqlDictionary   sqlDict;
SysdictType     dictType;
DictTable       dictTable;
DictField       dictField;
ArrayIdx        arrIdx;
Counter         numOfSqlFields; // number of records created in SqlDictionary
fieldName       fieldName;
fieldId         fieldId;
tableId         tableId = tablenum(TheTable2Fix);  // TARGET

boolean processTableField(
    DictField   _dictField,
    ArrayIdx    _arrIdx,
    boolean     _isTzIdField = false
    )
{
    ArrayIdx    dictArrIdx;
    str         infoName;       // this field name is for messages only
    FieldName   sqlName;
    boolean     ret;
    ;
    if (_isTzIdField)
    {
        if (    _dictField.baseType()   != Types::UtcDateTime
            ||  _dictField.id()         == fieldnum(Common, createdDateTime)
            ||  _dictField.id()         == fieldnum(Common, modifiedDateTime)
           )
        {
            throw error(Error::wrongUseOfFunction(funcname()));
        }
        dictArrIdx  = _dictField.arraySize() + _arrIdx;
        sqlName     = _dictField.dateTimeTimeZoneRuleFieldName(_arrIdx - 1);
        infoName    = _dictField.name() + #TZIDsuffix;
    }
    else
    {
        dictArrIdx  = _arrIdx;
        sqlName     = _dictField.name(DbBackend::Sql, _arrIdx);
        infoName    = _dictField.name();
    }
    select firstonly sqlDict
        where   sqlDict.tabId   == _dictField.tableid()
            &&  sqlDict.fieldId == _dictField.id()
            &&  sqlDict.array   == dictArrIdx
                ;
    if (!sqlDict)
    {
        sqlDict.clear();
        sqlDict.initValue();
        sqlDict.tabId           = _dictField.tableid();
        sqlDict.fieldId         = _dictField.id();
        sqlDict.array           = dictArrIdx;
        sqlDict.name            = strupr(_dictField.name(DbBackend::Native, _arrIdx));
        sqlDict.sqlName         = sqlName;
        dictType                = new SysDictType(_dictField.typeId());
        if (_isTzIdField)
        {
            sqlDict.fieldType   = Types::Integer;
        }
        else
        if (        _dictField.id()     == fieldnum(Common, RecId)
            ||      _dictField.id()     == fieldnum(Common, createdTransactionId)
            ||      _dictField.id()     == fieldnum(Common, modifiedTransactionId)
            ||      _dictField.typeId() == extendedtypenum(RecId)
            ||      _dictField.typeId() == extendedtypenum(RefRecId)
            ||  (   dictType
                &&  dictType.isExtending(extendedtypenum(RecId))
                )
           )
        {
            // This type is used instead of Types::Int64 for fields of type
            // RecId/RefRecId/createdTransactionId/modifiedTransactionId
            sqlDict.fieldType   = #RecIdBaseType;
        }
        else
        {
            sqlDict.fieldType   = _dictField.baseType();
        }
        sqlDict.strSize         = _dictField.stringLen();
        sqlDict.shadow          = bitTest(_dictField.flags(), #DBF_SHADOW);
        sqlDict.rightJustify    = bitTest(_dictField.flags(), #DBF_RIGHT);
        sqlDict.flags           = sqlDict.shadow;   // not _dictField.flags() at all!
        sqlDict.nullable        =   _dictField.baseType() == Types::Container
                                ||  _dictField.baseType() == Types::VarString
                                    ;
        if (sqlDict.validateWrite())
        {
            sqlDict.insert();
            ret = true;
            info(strfmt(@"Created record for field %1.%2%3",
                        dictTable.name(), infoName,
                        _dictField.arraySize() > 1 ? strfmt(@"[%1]", _arrIdx) : ''));
            // for all nonsystem UtcDateTime fields we also create a related TZID-field
            if (   !_isTzIdField
                &&  _dictField.baseType()   == Types::UtcDateTime
                &&  _dictField.id()         != fieldnum(Common, createdDateTime)
                &&  _dictField.id()         != fieldnum(Common, modifiedDateTime)
               )
            {
                processTableField(_dictField, _arrIdx, true);
            }
        }
        else
        {
            ret = checkFailed(strfmt(@"%1 record for %2.%3 was not created",
                                     tablestr(SqlDictionary), dictTable.name(), infoName));
        }
    }
    return ret;
}
;
dictTable = new DictTable(tableId);
if (!dictTable)
{
    throw error(strfmt(@"Failed to create %1 for '%2' (%3)",
                classstr(DictTable), tableid2name(tableId), tableId));
}
if (dictTable.isSystemTable())
{
    throw error(strfmt(@"'%1' is a system table, no way...", dictTable.name()));
}
if (!dictTable.isSql())
{
    throw error(strfmt(@"Table '%1' should not be in DB", dictTable.name()));
}
for (fieldId = dictTable.fieldNext(0); fieldId; fieldId = dictTable.fieldNext(fieldId))
{
    dictField = dictTable.fieldObject(fieldId);
    if (dictField && dictField.isSql())
    {
        fieldName = dictField.name();
        for (arrIdx = 1; arrIdx <= dictField.arraySize(); arrIdx++)
        {
            numOfSqlFields++;
            processTableField(dictField, arrIdx);
        }
    }
}
select firstonly sqlDict
    where   sqlDict.tabId   == tableId
        &&  sqlDict.fieldId == 0
            ;
if (!sqlDict)
{
    sqlDict.clear();
    sqlDict.initValue();
    sqlDict.tabId       = tableId;
    sqlDict.name        = strupr(dictTable.name());
    sqlDict.sqlName     = dictTable.name(DbBackend::Sql);
    sqlDict.strSize     = numOfSqlFields;       // for the table "header" - num of fields 
    sqlDict.flags       = dictTable.isView();   // that's the way it is
    sqlDict.insert();
    info(strfmt(@"Created record for table %1", dictTable.name()));
}

Best Practice checks for objects on the current layer only

2011-05-04T00:09:00.002+04:00

There are many Best Practice checks implemented in the standard AX application, which can help you to verify and improve your (or someone’s) source code and other application artifacts. But it should be noted that the execution of Best Practice checks:

Dramatically degrades compilation speed;
Is pointless for application objects that are not present on the current application layer.

So I decided to make Best Practice checks work only for objects on the current application layer. It turned out to be pretty easy to implement - all you need is add a new enum field to turn on or off this new behavior, for instance, to the SysBPParameters table and customize the SysBPCheck class a little.

private void doTreeNode(TreeNode _treeNode)
{
    TreeNodeTraverser   treeNodeTraverser;
    SysBPCheckBase      sysBPCheckBase;
    TreeNode            treeNodeToRelease;
    boolean             checkChildren = true;
    TreeNodePath        parentPath;
    int                 infologLines;

    Map map = new Map(Types::Integer, Types::Integer);
    MapEnumerator enum;
    int length;
    ;
    treeNodeToRelease = null;
//  if (_treeNode)                              //-gl00mie, 14.02.2011
    if (this.mustCheckTreeNode(_treeNode))      //+gl00mie, 14.02.2011
    {
        treeNodeTraverser = new TreeNodeTraverser(_treeNode);

        while (treeNodeTraverser.next()) // Check Best Practices
        {
            if (!sysCompilerOutput)
            {
                setprefix(treeNodeTraverser.infologPrefix());
            }

            treeNode = treeNodeTraverser.currentNode();
            if(treeNode)
            {
                length=strlen(treeNode.treeNodePath());
            }
            else
            {
                length=0;
            }
            if (treeNodeToRelease && SysTreeNode::isApplObject(treeNode) &&
                (treeNodeToRelease.sysNodeType()!= #NT_DBVIEW || 
                (treeNode && treeNode.sysNodeType()!= #NT_QE) ||
                length < strlen(treeNodeToRelease.treeNodePath()) ||
                substr(treeNode.treeNodePath(),1,strlen(treeNodeToRelease.treeNodePath())) !=
                treeNodeToRelease.treeNodePath()))
            {
                treeNodeToRelease.treeNodeRelease();
                treeNodeToRelease = null;
            }
//          if (checkChildren ||                        //-gl00mie, 14.02.2011
            if ((checkChildren ||                       //+gl00mie, 14.02.2011
                substr(treeNode.treeNodePath(),1,strlen(parentPath)) != parentPath)
                &&  this.mustCheckTreeNode( treeNode )) //+gl00mie, 14.02.2011
            {
                sysBPCheckBase = this.getSysBpCheckBase(treeNode);
                sysBPCheckBase.parmSysBPCheck(this);
                // ...

And here's the new SysBPCheck method that decides whether to run BP checks for a TreeNode:

// gl00mie, 14.02.2011
protected boolean mustCheckTreeNode(TreeNode _treeNode)
{
    UtilEntryLevel  applObjectLayer;
    UtilEntryLevel  currentAOLayer;
    boolean         ret;
    ;
    if (_treeNode)
    {
        ret = true;
        currentAOLayer = currentAOLayer();
        // if you develop on the sys layer then this modification is obviously pointless
        if (currentAOLayer > UtilEntryLevel::sys)
        {
            applObjectLayer = _treeNode.applObjectLayer();
            if (    applObjectLayer < currentAOLayer
                &&  enum2str(_treeNode.applObjectType()) != ''
               )
            {
                // depending on your setup we can skip BP checks for objects situated on lower layers
                // NB! you'll have to add this new field to a table and to a form by yourself
                ret = !SysBPParameters::find().CheckBPForCurrentAOLayerOnly;
            }
        }
    }
    return ret;
}

Query forceSelectOrder and forceNestedLoop hints are not saved when you pack and unpack a query

2011-04-30T11:33:00.008+04:00

In some situations it's useful to take a query from a form or a calling class, transform this query somehow and use in another part of the application. For instance, you might take a query from a form datasource to process all the records queried by the form, or take a query and transform it to count records that can be fetched by the query (what SysQuery::countTotal() does), or just pass a query object from one tier to another (client to server). In all those cases you would do something like this:

Query newQuery = new Query(oldQuery.pack());

Yes, I know that in case of a form datasource query you should also take care of dynalinks but this is not the point. The point is that you might not get the same execution plan for the resulting query because forceSelectOrder and forceNestedLoop hints are not preserved during query pack/unpack. This is true at least for the AX 2009 SP1 RU7 kernel (5.0.1500.4570) so for now if you use these hints you should not rely solely on the kernel when you copy a query. For this purpose you can create a SysQuery method like this:

/// <summary>
/// Copies a query including a one with dynalinks and hints
/// </summary>
/// <param name="_q">
/// source query
/// </param>
/// <param name="_copyHints">
/// must the forceSelectOrder and forceNestedLoop hints also be copied
/// </param>
public client server static Query copy(
    Query   _q,
    boolean _copyHints = true
    )
{
    QueryBuildDataSource    qbdsOld;
    QueryBuildDataSource    qbdsNew;
    QueryBuildDynalink      qbdl;
    QueryBuildRange         qbr;
    Query                   ret;
    str                     sq;
    Counter                 n;
    ;
    if (!(_q && _q.dataSourceCount()))
    {
        throw error(Error::wrongUseOfFunction(funcname()));
    }
    ret = new Query(_q.pack(false));
    if (_copyHints)
    {
        // Query methods forceSelectOrder() and forceNestedLoop() have mandatory parameters
        // so you cannot use these methods as ordinary properties to find out current values
        sq = _q.dataSourceNo(1).toString();
        if (match(@"^SELECT WITH.* SELECT_ORDER[ ,]", sq))
        {
            ret.forceSelectOrder(true);
        }
        if (match(@"^SELECT WITH.* NESTED_LOOP[ ,]", sq))
        {
            ret.forceNestedLoop(true);
        }
    }
    qbdsNew = ret.dataSourceNo(1);
    qbdsOld = _q.dataSourceNo(1);
    for (n = 1; n <= qbdsOld.dynalinkCount(); n++)
    {
        qbdl = qbdsOld.dynalink(n);
        // clear all existing ranges for this field
        while (qbdsNew.findRange(qbdl.field()))
        {
            qbdsNew.clearRange(qbdl.field());
        }
        // set the range value by the current dynalinked cursor field value
        qbr = qbdsNew.addRange(qbdl.field());
        qbr.value(queryValue(qbdl.cursor().(qbdl.dynamicField())));
        qbr.status(RangeStatus::Locked);
    }
    return ret;
}

AX 2009 client freezes and doesn't redraw its window during long operations (FIX!)

2011-04-30T00:42:00.010+04:00

Hey, it's been a long time since the last post!.. Anyway, when you run a long lasting operation in AX 2009, after about 5 seconds a client window would blink - and bam! it's in the Not Responding state and doesn't redraw anything. This behavior has been annoying me since I've first seen AX 2009 but now there seems to be a solution! I've found it accidentally in this post of the EMEA Dynamics AX Support blog. Here what they say:

...One reason for running into this issue can be if the Windows Operating System is replacing the Dynamics AX application window by a ghost window. When Dynamics AX starts a lengthy COM operation, it is not responding to messages sent by the Windows Operating System in time. So Windows supposes Dynamics AX has stopped responding. When this happens the Dynamics AX application window is replaced by a ghost window until Dynamics AX resumes. Window ghosting is a nice feature that allows the user to minimize, move or close the main window even if the application is not responding. You can easily identify a ghost window as it shows (Not responding) in the window title.

One of the proposed solutions is to run a client in the WinXP SP2 compatibility mode, but it requires you to create a special shortcut for it and run every deployed client with such a shortcut, which is not always convenient. But theres's also another way.

The Win32 API function DisableProcessWindowsGhosting can disable windows ghosting feature for the calling process and you can customize your Dynamics AX application to make the client call this function on startup. All you have to do is add a new method to the WinAPI class:

/// <summary>
/// Call user32.DisableProcessWindowsGhosting
/// </summary>
/// <remarks>
/// Disables the window ghosting feature for the calling GUI process. Window
/// ghosting is a Windows Manager feature that lets the user minimize, move,
/// or close the main window of an application that is not responding.
/// </remarks>
public static client void disableProcessWindowsGhosting()
{
    DLL         dll     = new DLL(#UserDLL);
    DLLFunction dllFunc = new DLLFunction(dll, @"DisableProcessWindowsGhosting");
    ;
    dllFunc.returns(ExtTypes::void);
    dllFunc.arg();

    dllFunc.call();
}

And then call it say from info.startupPost():

/*
No SYS code must exist in this method
*/
void startupPost()
{
    if (clientKind() == ClientType::Client)
    {
        // BP deviation documented
        WinAPI::disableProcessWindowsGhosting();
    }
}

This Win32 API function is supported in at least WinXP SP3 and Windows Server 2003 SP2. It's a pity windows ghosting is not disabled by the client kernel itself.

Book review: Microsoft® Office SharePoint® Server 2007 Best Practices

2008-10-29T23:48:00.004+03:00

Microsoft Press has started a very interesting "Best Practices" series with a book dedicated to a product sometimes called the next big ‘operating system’ from Microsoft. First off this is not a book for those just starting to learn how to install, configure, and administrate SharePoint Server 2007; there are some other books suggested for reading in this case. What is valuable in this book is that best practices presented in it (except for those few based on hard-coded limits in the product) are the essence of many, many discussions, analyzes, resolved support issues and numerous implementation projects undertaken by the authors. The book consists of four parts: Planning and Designing, Building, Deploying, and Operating. And although there are plenty of possible deployment scenarios for a SharePoint Server 2007, throughout each part of the book the authors present common threads of best practices that can be utilized across a number of different deployment scenarios. Your solid knowledge and understanding of these best practices built on the proper use of Microsoft SharePoint Products and Technologies will eventually lead to better and wiser design decisions: it will help you to efficiently map the features and functionalities in Microsoft Office SharePoint Server 2007 to your specific environment, culture, requirements and deployment. But let's take a look at the other side of technologies: not only they empower individual information workers but also bring a significant change in a corporate environment and power dynamics within an organization. It takes more than a creative idea or a unique skill to help solve a significant problem - you need allies within your corporation, and the more influence they have at the enterprise level of the corporation, the more likely it is that your deployment will be successful. Another point essential to your SharePoint Server 2007 implementation is the development of business requirements: clearly articulated, measurable, agreed upon and written down for the reference. Also a strong governance for a deployment is required to mitigate inevitable conflicts. As the authors mention,

Yet changes that can cause conflict that result in power wars, if not anticipated, discussed, and managed properly, can kill your deployment.

Sad but true, and what is especially valuable in the book is that besides diving into technical details the authors also discuss these less-talked-about sides of a deployment. Think about the power dynamics in your organization, thoroughly define business requirements prior to deployment and implement proper governance for the deployment itself. These are best practices at least just as important as those concerning security policy or an information architecture development, and you will be presented with an excess discussion of these best practices as well as numerous examples, notes from the field and lessons learned.

View AOCP/RPC Interface Version used by an Arbitrary DAX Binary

2008-09-30T15:48:00.008+04:00

First off a little bit of theory. Dynamics AX is a client-server application and utilizes a special protocol/interface for client-server communication. Namely versions prior to 4.0 used AOCP (Axapta Object Communication Protocol) implemented over TCP/IP and versions 4.0 and above have moved to an RPC interface. The client-server communication details inevitably change over time as kernel updates are released and obviously for robust Dynamics AX kernel operation it's vital to make sure that a client and a server understand each other precisely i.e. use the very same «dialect» of the communication protocol/interface. Hence an internal communication protocol/interface versioning is used in Dynamics AX kernel to find out if an arbitrary client can safely connect to and communicate with an arbitrary server. Those of you who has worked with Axapta 3 might remember that when you start a client with a kernel build number different from the AOS' kernel build number then the client most likely fails to connect to the AOS and complains about «Internal revision mismatch in Axapta Object Communication Protocol»; then it suggests to use the same kernel build for both client and Object Server. Why is it just a suggestion? First, the client has no idea if the server's kernel build matches it's own, and vice versa the AOS has no idea if a client attempting to connect has the same kernel build number as the AOS. Second, Dynamics AX clients and servers with non-matching kernel build numbers can connect and work with each other in case they use the same version of a communication protocol/interface. The first statement might look arguable. If you look in the User log (Administration/Inquiries/User log) you can find there some technical information about a user's session such as a client computer name, a client type and some kind of build number. Aha! So Object Server does know exactly the client's kernel build number, right? Wrong. A SysUserLog record which represents User log data is filled right in SysUserLog.insert() method. And while SysUserLog.Computername and SysUserLog.ClientType field values represent corresponding xSession object properties, SysUserLog.BuildNum field is initialized with a value returned by xInfo::buildNo() static method which has no explicit client or server modifiers. In 3-tier environment a table variable is generally located on the server side, hence SysUserLog.insert() and xInfo::buildNo() are executed on the server side and SysUserLog.BuildNum field receives server's kernel build number. So, once again, an AOS has no idea if a client attempting to connect to it has the same kernel build number or not. So when it comes to client/server interoperability, Dynamics AX kernel relies solely on the communication protocol/interface version, not kernel build numbers. And if that version is the same in client an server binaries then those binaries can be safely used together. But how can you know what communication protocol/interface version does an arbitrary Dynamics AX kernel binary use? Well, here is a utility for you: viewer for Dynamics AX AOCP/RPC interface version used by an given DAX kernel binary. Prior to a kernel binary file name you can pass these command line arguments:

-nosigcheck - omit Authenticode verification (useful for some legacy kernel builds that miss the Authenticode digital signature)
-debug - output additional technical information about the binary and print more detailed error messages if any

You now can easily find out (and check it out) that Dynamics AX 4.0 SP1 and SP2 binaries work together as they use the same RPC Interface version; and so do Dynamics AX 2009 TAP3 and RTM binaries...

Dynamics AX 2009 Guides and White Papers

2008-08-13T15:10:00.005+04:00

Run DAX4 AOS as a console application

2007-10-30T22:36:00.033+03:00

I've recently found an interesting feature of DAX4 Object Server: it can run not only as a service, but also as a console application started from command line. All you have to do is pass a <any_single_character>console parameter before the configuration number, e.g.

ax32serv.exe /console 01

This feature was probably added for debugging purpose as it's rather difficult to start a Windows service under a debugger. When started as a console application AOS can be terminated by pressing Ctrl-C or Ctrl-Break.

AX4 SysFileDeployment Fix

2007-07-10T10:55:00.050+04:00

In Dynamics AX it's often necessary to install some custom files such as ActiveX components, DLLs, templates, etc (that are not part of the installation package) on each client computer. There's a couple of handy classes to accomplish this task: SysFileDeployer and SysFileDeployment (and it's descendant SysFileDeploymentFile). Unfortunately this mechanism has been completely broken in AX4 due to Code Access Security covering «dangerous API» usage on the server tier, see Writing Secure X++ Code.

Implementing Code Access Security Code access security must be implemented by the dangerous API owner and all consumers of the dangerous API. 1. The owner secures the dangerous API by implementing a specific type of permission class and calling the demand() method on that class 2. Each API consumer must explicitly request permission to invoke a secured dangerous API by calling the assert() method on the permission class. Application code will break unless both of these steps are completed.

And everything is ok with the demand() calls in the WinAPIServer class whereas SysFileDeployment* classes lack the assert() calls. Probably they were not tested thoroughly or something… To be precise, here is what I've found:

SysFileDeploymentFile.serverVersion() lacks corresponding assert() call before WinAPIServer::getFileModifiedDate();
SysFileDeployment.getServerFileTimeAccessed()/Modified()/Created() lack corresponding assert() calls before WinAPIServer::getFileTime();
SysFileDeployment.isNameValid() splits full file name via fileNameSplit() and after that adds a redundant dot between the name and the extension (fileNameSplit() already returns file extension with a leading dot) - as a result isNameValid() always returns false which in its place causes corresponding assert() calls not to happen;
Finally, SysFileDeployment.sourcePath() returns xInfo::directory(DirectoryType::Include) by default and the latter is known to return different results depending on which (client or server) tier it is called. Of course, SysFileDeploy* classes work in such a way that SysFileDeployment.sourcePath() is called on both tiers - and that completely ruins all the program logic

You can download a small fix from axaptapedia.com to make SysFileDeployment work again. Microsoft claims there's already a hot fix with a description "File deployment error FileIOPermission failed", so there's a hope we will see this fixed in AX4 SP2...

Read Excel table via ADO

2006-12-20T11:29:00.001+03:00

I think it's quite a common task to read data from Excel files. A straight-forward way is to use Excel COM interfaces (Workbook, Worksheet, Range, Cell, etc), but damn it's slow! On the other hand there is ADO (ActiveX Data Objects) that is fast, flexible and familiar to many developers. So it would be nice to access Excel files via ADO to speed up data import and simplify application code.

Here is a utility class that allows reading Excel worksheets as Recordsets. It uses ADOX.Catalog to collect Excel worksheet names and ADODB.Connection, ADODB.Recordset to access worksheet data with a simple "select * from [sheetname]" Recordset's command.

A typical scenario would be something like this:

Counter         cnTotal = 0;
ItemId          itemId;
ItemName        itemName;
AmountCur       price;
Filename        strFilename;
container       conSheets;
ExcelImportADO  xlImport;
;
strFilename = @"c:\import.xls";
xlImport    = new ExcelImportADO(strFilename);
try
{
    // open the first sheet by default
    if (!xlImport.openFile())
    {
        throw error(strfmt("Error opening Excel file '%1'", strFilename));
    }
    if (xlImport.getFieldsCount() < 3)
    {
        throw error(strfmt("Too few columns in the recordset: found %1, expected at least %2",
                           xlImport.getFieldsCount(), 3));
    }
    while (!xlImport.eof())
    {
        itemId   = xlImport.getFieldValue(1);
        itemName = xlImport.getFieldValue('ItemName');
        price    = xlImport.getFieldValue('ItemPrice', false);
        // process data...
        cnTotal++;
        xlImport.moveNext();
    }
    xlImport.finalize();
    Box::info(strfmt("%1 records read", cnTotal));
}
catch (Exception::Error)
{
    xlImport.finalize();
}

You can download the source code of the class at axaptapedia.com. I would like to thank Gustav and blokva for inspiration and very useful tips on improving the class.

Note: ADOX.Catalog returns table names (Excel sheet names) in an alphabetical order - not in the order they appear in a worksheet, and by default the class uses the first name returned by ADOX.Catalog!

Dynamics AX and ADSI

2006-07-19T11:17:00.000+04:00

I've been using ADSI for a while during my work as a system administrator and I realy adore it but AX does lack Active Directory access facilities. There is only one built-in tool (as far as I know) to access AD from AX - that is ADObject class. But all it can do is find a user in the default domain and get some properties of it. To be precise it finds AD objects in the GetObject("LDAP://rootDSE").get("defaultNamingContext") using filter "(&(objectClass=user)(objectCategory=person)(sAMAccountName=%s))". AX supports COM objects (via IDispatch interface only), but if you try somehow to get an instance of IADs object you'll get an error so we should figure out how to get an IADs instance for a given LDAP path... Unfortunately it looks like there is no way to do this whithout an external tool. I'm planning to write a small COM object that will make possible for an AX application to get instances of ADSI objects for a given LDAP path. Later I'll tell what I managed to do...