Microsoft Dynamics NAV

Team Blog

March, 2008

  • Microsoft Dynamics NAV Team Blog

    Documentation Improvements in the Next Version of Microsoft Dynamics NAV



    Greetings from the Microsoft Dynamics NAV User Education team. We are the team responsible for application and platform documentation, including online Help, the Application Designer’s Guide, and install and config manuals. You’ve made some complaints, and we’ve been listening. Your feedback says that it’s difficult to find the Help information you need, and the content that’s there is “superficial” and “inadequate.“ As the team’s new Content Architect, I have been working with UE writers, editors and managers to make sure you have a better experience with the next release. In this post, I want to share a couple of the changes we’re making to the NAV docs for the next version: to describe business and development processes, and establish better discoverability of information.

    How Do I…

    Internally, we’ve been calling one new topic type, “How Do I” topics, because they’re written to answer the question, “How do I perform this process?” Here’s a draft of one of these topics, which basically answers the question, “How do I create new vendor accounts?”


    (click image to see larger size)

    The links at the top of the topic indicate where you are in the larger process – in this case, you are creating new vendor accounts as part of the section, Configure Purchase Processes , in the Purchasing department. The content of the topic includes overview information on the general sequence of tasks you perform to achieve a business or development goal, and then the table describes and links to topics to help you complete that goal. For application documentation, the processes are based on the customer model (


    Walkthrough topics provide end-to-end processes comprised of two or more tasks. Using the CRONUS International Ltd. demo company, the walkthrough tasks enable you to learn the steps involved in a process before you perform them using your own data. Application walkthroughs provide the beginning-to-end steps for processes like tracking sales campaign results, or calculating work in progress for a job. Development walkthroughs step you through processes like designing a customer sales order report.

    In coming weeks, we will begin sharing specific versions of these topics with you, and hope you’ll give us feedback on how well they meet your needs, and the specific content you’d like to see us develop.


    We’ve had a lot of feedback that finding information in the NAV documentation is difficult, so we’re working on improving discoverability from several angles. In previous versions, platform documentation has been delivered in nearly 20 different manuals. We’re compiling some of the most strategic of these manuals into online Help files for development, installation, and C/SIDE reference. These logical collections reduce the number of places you have to look for information, and since they’re Help files, you get the benefit of other discoverability aids like Search, an index, and a table of contents. In addition, platform documentation is going to be published in the MSDN library, for easy online access to topics.

    Other discoverability improvements include:

    • Role-based link pages that provide links to topics relevant to about 15 of the most common user roles.
    • Table of Contents remodel to incorporate all topics (except for field Help) into the table of contents, organized around the processes the topics support. This way, the TOC provides at-a-glance information about where you are in a process, and other information related to the topic you’re reading.
    • New overview topics like the one pictured above that provide navigation to high-level process topics, and link to the topics that support them.
    • Major index overhaul to make the index easier to use and a lot more robust. This includes adding keywords for business terms to help bridge the gap between NAV functionality and the terms you more commonly use for your tasks.

    Again, we welcome any suggestions, concerns, hopes, and fears you have regarding these plans or on the documentation as a whole. You can contact us directly at And if you are traveling to Convergence next week, please attend the User Education sessions we are running, on enabling partners to extend NAV Help, and on transforming forms for use in the RoleTailored client. Specific details are below.

    NAV Help Extensibility
    Tuesday, March 11, 12:30-1:30
    Room W311E

    NAV 2009 Form Transformation
    Thursday, March 13, 12:30-1:30
    Room W311E

    - Michelle Fredette

  • Microsoft Dynamics NAV Team Blog

    Sample of how to read a simple XML document using MSXML DOM in NAV


    This is a follow-up to the post "how to write a simple XML document". The other post conitains a few more background details which I won't repeat here. So even if you only want to read XML Documents, then you may want to have a look there anyway.

    But let's get straight to the point. This is how you can read an XML Document from Microsoft Dynamics NAV, using MSXML DOM: 

    1. Create a new codeunit.

    2. Declare these 5 new global variables:

    XMLDoc   Type = Automation 'Microsoft XML, v4.0'.DOMDocument
    DOMNode   Type = Automation 'Microsoft XML, v4.0'.IXMLDOMNode
    XMLNodeList   Type = Automation 'Microsoft XML, v4.0'.IXMLDOMNodeList

    CurrentElementName   Type = Text  30
    i   Type = Integer


    3. Initialize the Dom Document:

    4. Set up a loop to browse through the nodes in the document:
    XMLNodeList := XMLDoc.childNodes;
    for i := 0 to XMLNodeList.length - 1 do begin
      DOMNode := XMLNodeList.item(i);

    You also have to create ReadChildNodes as a function with one parameter:
    CurrentXMLNode, Type = Automation 'Microsoft XML, v4.0'.IXMLDOMNode.

    The reason for the functionis to enable you to run it recursively. This is useful because you don't know how many child nodes there are. And there can easily be a child node inside of another child node.

    So create the function ReadChildNodes.
    The function has one parameter:
    CurrentXMLNode : Automation "'Microsoft XML, v4.0'.IXMLDOMNode"

    And a number of local variables:
    TempXMLNodeList    Automation = 'Microsoft XML, v4.0'.IXMLDOMNodeList
    TempXMLAttributeList    Automation = 'Microsoft XML, v4.0'.IXMLDOMNamedNodeMap
    j    Integer
    k   Integer

    The function checks to see what type of node it was called with. A node can be an element, text (data), attribute etc. The node property .nodeType tells you which it is. See the documentation (included in MSXMLSDK) for a complete list of possible nodeTypes.

    This is the function:

    ReadChildNodes(CurrentXMLNode : Automation "'Microsoft XML, v4.0'.IXMLDOMNode")
    CASE FORMAT(CurrentXMLNode.nodeType) OF

    '1': // Element
        // Global variable CurrentElementName to keep track of what node
        // we are currently processing
        CurrentElementName := CurrentXMLNode.nodeName;

        // Process Attributes
        // If the element has attributes, then browse through those.
        TempXMLAttributeList := CurrentXMLNode.attributes;
        FOR k := 0 TO TempXMLAttributeList.length - 1 DO

        // Process Child nodes
        TempXMLNodeList := CurrentXMLNode.childNodes;
        FOR j := 0 TO TempXMLNodeList.length - 1 DO

    '2': // Attribute
        MESSAGE(CurrentElementName + ' Attribute : ' +
        FORMAT(CurrentXMLNode.nodeName) + ' = ' + FORMAT(CurrentXMLNode.nodeValue));

    '3': // Text
        MESSAGE(CurrentElementName + ' = ' + FORMAT(CurrentXMLNode.nodeValue));

    Now, try to run the codeunit against any XML document, and it will give a MESSAGE for each node and each attribute. This codeunit can be used for scanning any XML document from begin to end.


    Next example:

    Now, lets say you are looking for specific nodes in an XML document. As an example, take this document:

    - <Document>
    - <Order ID="1001">
    - <Line>
    - <Line>
    - <Order ID="1002">
    - <Line>
    - <Line>
    - <Line>


    One of the good things in MSXML DOM is, that it reads the whole document into memory, so you can jump between nodes, and browse them, and select sub-sets based on node names. So you do not have to read a document from top to bottom if you know exactly which parts of the document you are interested in.

    First, we can count how many orders the document contains (see how many "Order"-elements are under the root-element):


    XMLNodeList := XMLDoc.getElementsByTagName('Document/Order');
    MESSAGE('The document has %1 elements called Order',XMLNodeList.length);

    This will open the XML document, then use the getElementsByTagName-function to get all elements that match the tag name. Note that the tag name you specify is case sensitive (like everything else in XML)! So in this case, it would not find elements called "order".

    Once you have the XMLNodeList, then you can go through the nodes in that list, using the first example.


    Finally, an example which will read the XML document shown above, and show an Amount-total for each order:


    XMLNodeList := XMLDoc.getElementsByTagName('Document/Order');
    FOR i := 0 TO XMLNodeList.length - 1 DO BEGIN
      NumberDecTotal := 0;
      DOMNode := XMLNodeList.item(i);
      XMLNodeList2 := DOMNode.selectNodes('Line/Amount');
      FOR j := 0 TO XMLNodeList2.length - 1 DO BEGIN
        DOMNode2 := XMLNodeList2.item(j);
        NumberAsText := FORMAT(DOMNode2.text);
        NumberDecTotal := NumberDecTotal + NumberDec;
      MESSAGE('Order has total amount of %1.',NumberDecTotal);


    This example uses DomNode.SelectNodes, which will select all matching nodes. If you are looking for an individual node, then you can use DomNode.selectSingleNode which will only return one node (the first that matches).

    In an XML document, everything is Text. So you have to convert to numbers where needed. Final note: Make sure to make your code more robust than this! What if Amount contains a character? What if an element is missing? If you don't take these things into consideration, then your code can fail with very unfriendly errors.


    These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use. 


    Best regards

    Lars Lohndorf-Larsen (Lohndorf)

    Microsoft Dynamics UK

  • Microsoft Dynamics NAV Team Blog

    What is SEPA?


    We get a couple of questions asked quite regularly: “How can I make my ERP system SEPA compliant” and a more basic one “What is SEPA? And how does this affect my daily work?” With this blog entry I’ll try to answer these questions.

    SEPA is short for Single European Payment Area – which is set up by the European Commission as a political agreement to reinforce the Economic Monetary Union. The goal is to form a single market for payment transactions within the European Economic Area. One of the ways to do this is to create a set of standards for electronic payments using ISO20022 XML format together with a set of rules and guidelines as to how Euro payments must be handled. With SEPA fully implemented, all electronic payments in Euro within the SEPA area will be regarded as domestic payments - even if they are cross-border payments.

    With a common standard it will be easier to process payments, which will lead to more efficiency in the banking system and hopefully lower prices. It will also make it possible for companies that have business activities in many countries to only interact with one bank, since the cross-border payment is assumed to be the same as the domestic payment. The long term vision is that this standard can expand and also be used in other areas such as e-invoicing and e-reconciliation.

    The SEPA implementation is still in its early stages. In January 2008, the SEPA instruments for Credit Transfer became available to be used. The Credit Transfer standard will be initially used for interbank relationships with regards to cross boarder euro payments within the SEPA Countries. Banks which talks about SEPA compliant refer to this fact, meaning that they are able to create these kinds of transfers. It is important to note that right now it is only required that banks can use this format when dealing with each other; it is not required that customers adhere to these standards in either customer-to-customer or customer-to-bank situations. It is also important to note that the SEPA only covers Euro transactions – not other currencies.

    Looking forward it is expected that national instruments for credit transfers, direct debits and cards are replaced by the relevant SEPA instruments by 2010 and that customers will be able to use the standards for creating electronic payments.

    This will affect Microsoft Dynamics NAV customers that have banking relationships within Europe. Short term there will not be a big difference – it will not be required that customers use the SEPA standard, when they interact with their bank. Furthermore it is also only a few banks that can accept the format today. It will be possible to ask the bank for a SEPA Credit Transfer, but it will be the bank that creates the file in the proper format. It is anticipated that many of the banks within the SEPA region will be able to receive a SEPA Credit Transfer in the near future, but it is expected that there will be a transition period where they accept the old electronic formats.

    One thing to prepare for is that both Bank Identifier Code (BIC) and the International Bank Account Number (IBAN) is a crucial part of the SEPA standard. These two identifiers are needed to process a SEPA Credit Transfer. This mean these numbers will have to be correct when an electronic payment is created and is something that the customers can prepare for by requiring that these fields are used and updated when a customer or a supplier is created or updated in Microsoft Dynamics NAV.

    One question that we also hear and want to comment on is “If I want to make a SEPA payment, am I required to create an ISO 20022 compliant XML file”? The answer to this is both Yes and No:

    • No because all you need to make a SEPA payment, is to instruct the bank to process the payment according to the SEPA rules.  In short, this means that the payment must be in euros within the EEA and IBAN and BIC must be supplied.  There are several ways to create this payment:
      1. A company or individual can make a payment using the software provided by their bank.  The necessary information can be entered via the banking software.  The bank must then process the payment according to the SEPA rules.
      2. A company or individual can create a payment file and upload this to the bank for further processing.  This file may be an ISO 20022 XML file, but it is not mandatory.  A bank can offer to accept the existing payment files and process these according to SEPA rules if they are able to fill in missing information such as IBAN or BIC to fulfill the SEPA rules.  The bank is free to charge a fee for this conversion service. 
    • Yes because a bank is free to demand that ISO 20022 XML files are supplied in order to process payments according to the SEPA rules – It depends on your bank.

    There are many places on the internet where it is possible to get more information on what SEPA is and what it means to businesses in EU and to banks. Many banks are also aware of the changes to come and what effect it has to their customers. I hope that the points above indicate that SEPA is an interesting new standard that potentially can make it possible to make interactions between Microsoft Dynamics NAV and banks more effective. From our perspective a common standard will make it possible for us to create bank integration that can serve more than one country or one bank – given that the banks stick to one schema! In the short term the thing to keep in mind is that it is possible to prepare for this by updating the data on supplies and customers, so that the creation of a SEPA compliant credit transfer can be created when it is required.

    Some facts around SEPA

    1. The purpose with SEPA is to create standardized payment instruments that can be used within all SEPA countries. The goal is to simplify and reduce the cost of payment flows, to facilitate trade and commerce and to strengthen the competitiveness.
    2. The European Commission (EC) and the European Central Bank (ECB) are responsible for introducing and administrating SEPA
    3. The countries involved in the SEPA agreements are: All member states in the Euro Zone incl. the EEA countries that are not part of the EU (Iceland, Liechtenstein, Norway) and Switzerland.
    4. The SEPA Schemas defines a common set of rules, processes, service levels and timeframe for each of the payment instruments. The ISO20022 is the standard for these payment instruments.
    5. Banks can adhere to the compliance requirements and thus become SEPA compliant. There is no corresponding compliance requirements for ERP solutions at the moment.
    6. SEPA covers the following payment instruments
      • Credit transfers
      • Direct Debits
      • Cards
    7. Payment Service Directive (PSD) is the legal framework approved by EC and applied to all EU member states. It provides a new EU-wide licensing regime for Payment Institutions, so that non-bank payment service providers can offer their services across the eurozone. The PSD provides rules for information requirements which Payment service providers must fulfill. This applies both to SEPA and to existing national payment products.
    8. Businesses are not required to make SEPA payments from January 2008. It will be possible to use both national payments standards and SEPA standards in a transfer period. SEPA payments are not anticipated to be able to replace national payment instruments until end 2010 in some of the involved countries. In some it will even be later.
      • Several countries (for instance Belgium, Finland, Portugal and Spain) have committed to phase out the old payment instruments by 2010
      • Some countries are committing to an extended deadline (for instance, Netherlands has committed to a deadline of 2013, France has committed to a deadline of 2010 for cards, 2011 for credit transfers and 2012 for direct debits)
      • Many countries (for instance Germany, Austria and Ireland) have not indicated a migration deadline
    9. A SEPA credit transfer is a payment from one company or individual to another company or individual. The payment must be in euros and it transaction must include IBAN and BIC for both parties. One important point to remember is that credit transfers should be conducted between parties by means of XML files that comply with ISO 20022 payment processing standards and the XML format as specified by the European Payments Commission.
    10. SEPA Directs Debits are somewhat different from the national direct debits. The existing direct debits payments can only be done with each domestic market. It is not possible to collect a direct debit from a customer’s bank account in another country. With SEPA it will be allowed to have direct debit transactions from customer bank accounts in the EU. The adoption of SEPA direct debits requires new European legislation (the Payment Services Directive) that must be transposed by the legislatures in each of the EU Member States by 1 November 2009.

    Interesting links

    From the European Payment Council

    From the European Central Bank

    From the European Commission

    - Rikke Lassen

  • Microsoft Dynamics NAV Team Blog

    Microsoft Dynamics NAV, SQL Server 2008 and Windows Server 2008


    Microsoft Dynamics NAV plans to support Microsoft SQL Server 2008 and Microsoft Windows Server 2008 once they are available. To ensure compatibility, Dynamics NAV development will start testing Dynamics NAV 4.0 SP3 and Dynamics NAV 5.0 SP1 on these two server platforms at the beginning of calendar year 2008.

    See full announcement here.

    Martin Nielander (martinni)
    Program Manager

  • Microsoft Dynamics NAV Team Blog

    Simple query to check the recent blocking history


    SQL Server 2005 keeps (some) history of the number and time that blocking occurred on indexes. This blog contains a query that queries this information to help identifying on which tables blocking happens most. The query shows accumulated numbers (no. of blocks, wait time, etc) since SQL Server was last restarted.

    The query does have some known in-accuracies. Also, the result needs to be interpreted: It may not point directly at which indexes need changing or disabling. See below for details about this.

    The query uses Dynamic Management Views, which means it will only work from SQL Server 2005 and later. 

    Make sure to run the query in the NAV database, otherwise you won't see the table names.

    So, here it is:

    --Use [NAV-Database]


    db_name(database_id) DB,

    object_name(object_id) Obj,

    --row_lock_count, page_lock_count,

    row_lock_count + page_lock_count No_Of_Locks,

    --row_lock_wait_count, page_lock_wait_count,

    row_lock_wait_count + page_lock_wait_count No_Of_Blocks,

    --row_lock_wait_in_ms, page_lock_wait_in_ms,

    row_lock_wait_in_ms + page_lock_wait_in_ms Block_Wait_Time,


    from sys.dm_db_index_operational_stats(NULL,NULL,NULL,NULL)

    order by Block_Wait_Time desc

    --order by No_Of_Blocks desc

    No_Of_Blocks is recorded accurately, but the Block_wait_time is not. SQL Server only records Block_wait_time when the block is a clear pagelock or rowlock. It will not record wait_time in case of a rangelock, which is common in NAV. Also, Block_Wait_Time only gets recorded when a transaction completes. So if a transaction is aborted after the block (for example by Lock-Timeout), then Block_Wait_Time for that transaction will not be counted. This means that the real Block_Wait_Time is likely to be higher, and it may be distributed on different tables / indexes than the query shows. Anyway, I hope the query is still accurate enough to give a good idea about where blocking occurs.

    How to interpret the result:
    The query shows blocking per index. But you should not put too much importance in the individual index that shows blocking. Instead, look if there may be other indexes in that table which are not used. Remember, an update on Index X may require update on all other indexes in the table. So look at the whole table when deciding if the table is over-indexed. For this, use the query "Index Usage", which shows you the usage of each index in a table.

    Blocking will happen on the first table in a process which is blocked. Maybe the process begins processing small tables, but the real blocking happens because processing of other tables takes a long time. In that case, the query will show the blocking on the first table, but not show blocking on the later tables, which may be where the real problem is.

    I will be more than happy to receive any feedback on experiences with this query, and suggestions for how to improve it! 

    Lars Lohndorf-Larsen (Lohndorf)
    Escalation Engineer

  • Microsoft Dynamics NAV Team Blog

    Release of Microsoft Dynamics NAV 5.0 SP1


    It is with great pleasure that I can announce the release of Microsoft Dynamics NAV 5.0 SP1. During today the first countries will be available from PartnerSource and I would really like you to pay attention to the following two web sites on PartnerSource:

    Microsoft Dynamics NAV 5.0 SP1 General information:

    Microsoft Dynamics NAV 5.0 SP1 Download Information:

    Microsoft Dynamics NAV 5.0 SP1 Release Plan:

    March 28, 2008:
    Release in United States, Germany and Denmark. This is also the release date for the W1 version of Microsoft Dynamics NAV 5.0 SP1.

    May 7, 2008:
    Release in Australia, New Zealand, Canada (EN+FR), France, India, Indonesia, Ireland, Italy, Malaysia, Netherlands, Philippines, Singapore, Spain, Thailand and United Kingdom.

    June 17, 2008:
    Release in Austria, Belgium (NL+FR), Finland, Iceland, Mexico, Norway, Sweden, Russia, Czech Republic, Slovakia, Estonia, Hungary, Latvia, Lithuania, Poland, Portugal, Switzerland (FR+IT+DE), Bulgaria, Croatia, Romania and Slovenia

    These postings are provided "AS IS" with no warranties and confer no rights.
    You assume all risk for your use.

    Martin Nielander
    Program Manager
  • Microsoft Dynamics NAV Team Blog

    Sample of how to write a simple XML document using MSXML DOM in NAV


    This post if for when you need to export data in the form of XML from Microsoft Dynamics NAV. If you are not familiar with how to program with MSXML DOM, then it can take a lot of time and work to create even a simple XML document. The purpose of this post is to show a simple example, and to get you started programming with MSXML DOM from NAV.

     I have split this into two posts: "How to write" (this post), and "How to read" an XML Document (click here), since the methods and functions used are quite different.

    Why not just use XML-Ports? You can of course, but then you limit yourself to the functionality and limitations that exist in XML-Ports. An example of a limitation in XML-Ports is that they do not support namespaces. If you think that one day you may need functionality that is not supported by XML-Ports, and for which you have to use MSXML DOM anyway, then consider to just use MXSML DOM from the start. It is more complex to begin with, but once you have a set of functions to add / search etc elements in an XML document, then it does not have to be much more complex than using XML-Ports. Note that it is not possible to access an XML docuemnt via MSXML DOM from an XML-Port while the XML-Port is accessing it. The two methods are mutually exclusive.

    An XML document is organized as a heararchy of elements, and everything (elements and data) gets added piece by piece to existing elements.

    Let's get started with the simplest possible XML DOcument:

    Create a new codeunit with 3 variables:
    Name     DataType Subtype Length
    XMLDoc     Automation 'Microsoft XML, v4.0'.DOMDocument 
    DOMNode     Automation 'Microsoft XML, v4.0'.IXMLDOMNode 
    DomTextNode     Automation 'Microsoft XML, v4.0'.IXMLDOMText 

    In this example I use MSXML version 4, but you can use version 5 or 6 if you prefer. Version 4 is mostly used because it most likely contains all the functionality you will need, and it will be backward compatible to more machines - even old ones.


    Initialize the document:


    Unless you have specific reasons not to, set asynch = FALSE. Especially when you are reading an XML document. It means that it will load the whole document into memory before it starts reading through it. If you don't set this property, you may begin to process the document before it is completely loaded into memory.

    Now create a new node, and then add it to the document:

    DOMNode := XMLDoc.createNode(1,'NodeName','');

    Then add some data. This is done in the same way as you add an element: Creat the element first, and then add it to the right place in the document:

    DOMTextNode := XMLDoc.createTextNode('NodeValue');

    You can add any additional elements like this: Creat the element of the type that you need (node, text, attribute etc), and then append it to the document. 

    To see the document, save it to disk:'C:\XML\MyXML.xml');

    Note: If you run on Vista, it might not allow you to save files on the root of the c: drive. So create a new folder, for example c:\XML\

    Then run this codeunit. You should get a very simple document like this:

    If you want to add further nodes to this document then repeat the steps above to create a new node, then append it to an existing node. For example, to add a new node:

    Create a new variable:
    NewDOMNode : 'Microsoft XML, v4.0'.IXMLDOMNode

    Initialize the new node:
    NewDOMNode := XMLDoc.createNode(1,'NewNode','');

    And add text to the new node:
    DOMTextNode := XMLDoc.createTextNode('NewNodeValue');

    Now, your xml document will look like this:

    - <NodeName>


    Adding namespace and Attributes:

    You can add a name space either to the whole document, or to individual nodes. To add a name space to the document, go back to the relevant line above, and specify the 3rd parameter:

    DOMNode := XMLDoc.createNode(1,'NodeName','MyNameSpace');

    Finally, adding an attribute to a node is similar to adding a text element: Initialize the Attribute, then add it to the relevant node. Use the function SetNamedItem to add attributes. Let's add an attribute called ID with the value 10000:

    Create a new Automation variable:
    XMLAttributeNode : 'Microsoft XML, v5.0'.IXMLDOMAttribute

    Initialize the attribute, then add it to the node:
    XMLAttributeNode := XMLDoc.createAttribute('ID');
    XMLAttributeNode.value := '10000';

    The whole codeunit should now look like this:

    // Initialize the document
    // Create Node and attach it to the document. Use name space MyNameSpacefunction
    DOMNode := XMLDoc.createNode(1,'NodeName','MyNameSpace');

    // Add data (text) to the node
    DOMTextNode := XMLDoc.createTextNode('NodeValue');

    // Add an attribute to the node
    XMLAttributeNode := XMLDoc.createAttribute('ID');
    XMLAttributeNode.value := '10000';

    // Initialize a new node:
    NewDOMNode := XMLDoc.createNode(1,'NewNode','');

    // And add text to the new node:
    DOMTextNode := XMLDoc.createTextNode('NewNodeValue');

    // Finally, save the document for viewing:'C:\XML\MyXML.xml');

    Further references:

    MSXML is further documented in MSXML Software Development Kit (MSXMLSDK). I would recommend that you download this to have the online help available for all of the MSXML DOM functions.


    These postings are provided "AS IS" with no warranties and confer no rights.
    You assume all risk for your use.


    Lars Lohndorf-Larsen (Lohndorf)

    Microsoft Dynamics UK
    Microsoft Customer Service and Support (CSS) EMEA

Page 1 of 1 (7 items)