mfp's two cents

...on Dynamics AX Development!

  • mfp's two cents

    AX 2012 R2 CU7 has been released!


    Cumulative Update 7 for Dynamics AX R2 has been released today!  Download it from Partner Source or Customer Source.

    Besides 60 country specific regulatory updates and many quality improvements, these areas have been enhanced:


    What’s new


    Accounts payable

    • New options for configuring workflows for vendor invoices.
    more info

    Accounts receivable

    • External documents can now be sent as email to a customer or vendor by using the email address that is specified by the address purpose field. Any report can be sent as email to an internal employee by using the worker title.
    more info


    • You can create a budget plan worksheet template for Excel by using a wizard in Microsoft Dynamics AX.
    • The budget allocation process is easier, because you can use ledger allocation rules for budgets.
    • Budget planning workflows can be set up so that they can’t be accidentally deleted or reset.
    • Budget planning workflows can be set up so that they require a parent budget plan.
    • You can specify whether budget planning user groups (XDS policies) are used for budget planning. You can also specify the number of associated budget plan lines to include when budget plans are exported to Excel.
    • You can view worksheet and justification documents from the Budget plan page in Enterprise Portal for Microsoft Dynamics AX.
    • The process of creating a budget plan from an existing budget plan is enhanced.        

    more info

    Fixed assets

    • You can now transfer more than one fixed asset at the same time.
    • The acquisition cost of fixed assets can include a miscellaneous charge amount.
    • The process for acquisition proposals or depreciation proposals for fixed assets can now be run in a batch process.

    more info

    General ledger

    • An Excel template for journal entries is included on the virtual machine for demo data.
    • More understandable posting messages for journal lines that have errors in the account combination.
    • Delete an unposted journal that contains lines.
    • View advanced rules for a main account.
    • Easier dimension setup for Excel integration.
    • Display dimensions in a specified order in Management Reporter.

    more info

    Human resources

    • New preparation reports available to help make it easier for employers to complete mandatory human resource reports.
    • Changes to the forecast positions area .
    • You can require additional details when worker information is entered or changed, and optionally enable workflow.         

    more info

    Inventory and warehouse management

    • New On-hand entries cleanup batch job can be used to delete unused entries for serialized on-hand inventory, helping to improve the performance of queries for on-hand inventory.
    • You can combine two or more inventory batches into a new or existing batch.
    • Added new Role Center for costing and inventory valuation.

    more info


    • You can mass update benefit rates for workers.
    • Tiered contribution calculation rates for retirement benefit plans.
    • Create and update payroll tax groups.
    • Preparation of regulatory compliance reports for payroll.
    • Separate positive pay statements for Payroll bank accounts.

    more info

    Procurement and sourcing

    • Financial dimensions can be specified on sales agreements or purchase agreements.
    • A Totals FactBox is added to the Purchase orders list page.

    more info

    Product information management

    • You can determine prices using a product configuration model.

    more info

    Production control

    • Case management functionality is enhanced for documenting and releasing product changes to production.

    more info

    Project management and accounting

    • Use Microsoft Project to create or update a Microsoft Dynamics AX project plan, and integrate with an Office 365 SharePoint project site.
    • Use Microsoft Project to create or update the work breakdown structure (WBS) for a Microsoft Dynamics AX project quotation.
    • Create a WBS template for Microsoft Dynamics AX by using Microsoft Project.
    • Expanded support for working with project teams, defining project role types, and managing projects.
    • Expanded support for managing worker assignments and capacity in projects.
    • Enable audit trails on timesheet entry and reporting.
    • Improved management of project tasks in a WBS.
    • Improvements for creating WBS templates for project tasks.
    • Intercompany pro forma invoices for project costs.

    more info

    Public sector

    • The configuration keys for public sector organizations in France are enabled by default, hence the primary address of the organization no longer has to be in France if you want to use the French public sector accounting rules.
    • You can now dispose of more than one fixed asset at the same time.

    more info


    • Prompt for a reason code when the cashier opens the cash register drawer without performing a sale transaction.
    • You can post store transactions from statements based on the end of the business day instead of the calendar day.
    • You can use a new statement method to calculate statements by shift.
    • Passwords can now be changed and reset in Microsoft Dynamics AX for Retail POS.
    • Cashiers can view additional customer account information in Retail POS.

    more info

    Sales and marketing

    • You can calculate the sales price of an item by using an attribute-based pricing formula.

    more info

    Backup and recovery

    • We have added functionality for backup and recovery for cumulative update 7 for Microsoft Dynamics AX 2012 R2.

    more info

    Data import, export, migration

    • As of CU7, the Data Import/Export Framework is shipped as part of AX instead of as an add-on.

    more info

    Office Add-ins

    • Improved performance when you use the Office Add-ins. A new Validate dimensions button helps you locate and correct financial dimensions that were entered incorrectly or that are suspended.

    more info


    • PowerShell commandlet to install multiple instances of SSRS on the same SQL server
    • SSRS is primed after restart to speed up "first time" execution of reports
    • Can send reports to people using a token (@<Job Title>@) instead of being forced to name people explicitly
    • MorphX compare tool enhanced to support reports
    • Management Reporter can now be installed with primary AX setup

    more info

    Sales tax processing

    • Sales taxes and ledger accounts can be reconciled more easily.
    • Performance is improved for tax reporting.
    • You can post of sales tax amounts for intercompany transactions to either the source legal entity or the destination legal entity.

    more info

  • mfp's two cents

    Microsoft Dynamics AX 2012 R2 is here


    If you, like anyone else, want to get your hands on R2 – here are the links for customers and partners.

    R2 is an incredible engineering achievement. Let me mention just one remarkable improvement: We have collapsed all GLS layers into the SYS layer. This means that for the first time you can have one instance supporting local requirements in 41 countries simultaneously. Learn more here. I’m proud to have been part of the team making it happen.

    With any great product launch a lot of material is made available. That is also true for R2 – and yet something stands out. In collaboration with Microsoft Studios a number of short videos have been created. I think they are truly amazing – what do you think? Try out the links below.

    What does it feel like to be in control, highly responsive, agile, connected and dynamic?

    Explore in the lives of a; CIO, CFO, HR Manager, Practice Manager, Retail Manager and a COO of Manufacturing.


    For more information see

  • mfp's two cents

    AX models - Part 1 - Deploying models


    About a milestone ago I announced SQL AOD. Since then it has been quite quiet on my blog - for two reasons 1) I've been heads down in new features and 2) I've been on paternity leave. Now the completion of M2, the next milestone of AX "6", is within reach and I've returned to my office. This means I can share some more exciting news.

    Since the days of AOD files are numbered we need a new vehicle for deploying metadata elements to an AX installation. To address this need we introduce Models. A model is a containment of metadata elements.

    To create a model you use the new command line utility AxUtil:

    AxUtil create /model:"My Model" /Layer:USR

    This will create a new model with the name "My Model" in the USR layer. This new model can be selected in the AX client configuration utility as the default model. When you start AX the status bar will tell you which model you are currently working in - just next to where the current layer is shown. When you make changes in the AOT, like overlayering elements, creating new elements, changing X++ code etc., the resulting elements will automaticaly be contained in your model.

    When you have completed all your changes, then your model is complete. In other words it is time to move the model from your developer box to a production system. In AX2009 you would copy your AOD files - with models you need to export it to a physical file. Again you will use AxUtil:

    AxUtil export /model:"My Model" /file:MyModel.axmodel

    Now you can copy this file to the production system and import it there:

    AxUtil import /file:MyModel.axmodel

    You can even uninstall it again - if that is what you want. This is semantically the same as deleting an AOD file in AX2009:

    AxUtil delete /model:"My Model"

    So far I have described the model capabilities that gives parity with AOD files: We have a file based container that can be xcopy deployed and we can delete models again.

    From what I've described so far models aren't much different than layers and AOD files. They are; and provide some highly desirable capabilities - which will be the topic of a near-future post - so stay tuned.

    This post is a part of a series on models:

    1. Deploying models
    2. Manifest and signing
    3. Multiple models per layer
    4. Working with models inside MorphX

    This posting is provided "AS IS" with no warranties, and confers no rights.

  • mfp's two cents

    Demo data for Microsoft Dynamics AX 2009 is released


    Demo Company Overview

    The Demo Data set for Microsoft Dynamics® AX 2009 is no longer based on the Global Trade and Manufacturing Company. Based on market feedback we have created a new Contoso Entertainment systems group of companies. It comes with 2 fiscal years of transactional data that enable us to demo our stronger Business Intelligence story and Role Center pages, while allowing us to easily expand the demo data story in future releases as we expand Microsoft Dynamics® AX’s functionality footprint.

    Contoso Entertainment Systems (CES) is a home electronics manufacturing, distribution and retail company that includes a Professional Services department. Its headquarters are in the USA with a key distribution subsidiary based in Germany and it works with the relevant currencies. CES distributes televisions, projectors, Digital Video Recorders and Players, and audio receivers. It manufactures speakers and assembles home theatre systems. CES’s customers are primarily based in North America and Europe and include Major Accounts (such as hotel chains), Wholesalers (of differing sizes), Retail stores (that are self-owned and operated), as well an internet storefront.

    The legal and physical structure of CES is setup as follows:

    ·          CEC – Contoso Entertainment Consolidation, based in USA

    ·          CEU – Contoso Entertainment USA, Headquarters based in USA

    o    Site 1: Production of all speakers

    o    Site 2: Assembly of home theatre systems and Services

    o    Site 3: Production of Standard speakers

    ·          CEE – Contoso Entertainment Europe, Distribution subsidiary company based in Germany

    o    Site 4: Distribution, Assembly and Service of all products

    ·          CVC – Virtual company that includes table collections from CEU and CEE.

    The downloads for Contoso Entertainment Systems demo data offers transactional data for Basic, Administration, General Ledger, Bank, Fixed Assets, Accounts Payable, Accounts and Receivable, Inventory Management, Intercompany, Production, Master Planning, CRM, Project, Expense Management, and Human Resources modules, and is intended to demonstrate these modules’ functionality. It also offers base data (i.e. no transactions) for the Product Builder modules. There is no demo data available for Payroll and Cost Accounting modules.






  • mfp's two cents

    X++ Debugging Tips and Tricks #3–Conditional breakpoints


    The Dynamics AX Debugger doesn’t support conditional breakpoints. Once in a while this limitation can be quite annoying – but there is a simple workaround. The third trick in the series of X++ Debugging Tips and Tricks shows you how.

    This trick requires code instrumentation – I strongly discourage using this trick on a production system. Only use this trick in a test or development sandbox!        

    By using the breakpoint keyword, you can write X++ logic that triggers a breakpoint exactly as you want.

    Consider this example. It is a recursive implementation of the mathematical function: Factorial. On a 32 bit system it will overflow when called with a sufficient high value. The example shows how to a breakpoint when an overflow occurs.

        static void ConditionalBreakpointExample(Args args)
            int factorial(int _value)
                int result = 1;
                int prevResult;
                int i;
                for (i=1; i<=_value; i++)
                    result = result * i;
                    if (result < prevResult)
                        breakpoint; //Overflow occurred
    prevResult = result; } return result; } factorial(maxInt()); }

    The same approach can be used in many other scenarios too. Here is another example – I’d like a breakpoint to fire when a Released Product with Item Id “1000” is inserted in the database. To achieve that I add the following to the insert method on the InventTable table.

        if (this.ItemId == "1000")

    There is another way to achieve the same result. You can also insert a no-op line, like i=i; and set a normal breakpoint on that line using F9. This approach has the benefit that only the user setting the breakpoint will hit it – but at the risk of leaving some “silly looking code” behind. In contrast the breakpoint statement triggers a best practice error – so they are easy to clean out again.

    Bonus trick

    There is another usage of the breakpoint statement. Sometimes regular breakpoints in forms don’t fire – here the breakpoint statement also comes in handy. Instead of setting a breakpoint using F9 – just type “breakpoint;” in the code. This will trigger the debugger.

    This post is provided AS-IS, and confers no rights or warranties.

    X   Debugging banner 2

  • mfp's two cents

    AX models - Part 3 - Multiple models per layer


    In my first two posts on models in AX (Part 1 and Part 2) I covered the deployment specific behaviors of .axmodel files - it should be apparent we introduced .axmodel files as a deployment replacement for AOD files. In the process we added some nice capabilities like a manifest and signing. The real benefit of models, and the ultimate reason we are adding this level of abstraction is because:

    You can have as many models per layer as you want.

    Let us examine this statement. In AX2009 a layer is the confinement unit of model elements. The layer is the unit of which you can export, deploy and delete model elements. (Here I'm deliberately ignoring the capabilities provided by XPO files, as these are suitable for development purposes only, and not deployment.) In AX6 this limitation has been removed, that means you can segment your layer into as many models as you like.

    Here are a few examples where this could be useful in development scenarios: 

    • If you deliver more than one solution:
      You can have a model for each of the solutions you are working on. This enables you to work on them simultaneously while having visibility into which model you are working on.
    • If your solution is getting too big:
      You can segment your solution into several models - and have teams/team members work on their own model. The models can be either self-contained or have dependencies to other models. This enables you to clearly define ownership between the models, clearly define the APIs between the models, build the models individually, etc.
    • If you write unit test:
      You can have a model for your production code and a model for your unit tests. This enables you to easily import all your unit tests, run them, and remove them again from the system.

    Let's examine the statement a bit deeper. There are two ways of getting a model: Either you create one on your own, or you receive it from someone else. If you can have as many models as you want per layer, it also means:

    You can deploy models from several sources into the same layer.

    Here is an example: You are a customer and would like to install two ISV solutions that both are available in the BUS layer. In AX2009 you would have a tough choice to make: Either you picked your favorite solution and learned to live without the other one, or you invested in having the two solutions merged into one layer. This merge is technical challenging, and a costly affair once updates to either solution are being released. In AX6, however, you download the two models, and use AxUtil to import them. When a new version of either model is released, you simply use AxUtil to update the model.

    The catch

    This all sounds too good to be true, what is the downside? There is one limitation to what a model can contain:

    An element can only be defined once per layer.

    This means that two models containing a definition of the same element cannot be installed in the same layer. For example; if the two models both contain a class named: "MyClass" they will not be able to install side-by-side in the same layer. Model elements have two alternate keys, they are: [Type, Parent, ID] and [Type, Parent, Name]. Each layer can only contain elements that can uniquely be identified via the two alternate keys. In less technical terms, this means that two elements of same type under same parent (or without a parent) cannot co-exist if they have same name or same ID. For example: A table cannot have two fields with same name, or two fields with same ID. Another example: You cannot have two display menu items with the same name.

    There are three ways you can be hit by this limitation:

    1. You create an element, and give it a name that accidentally also has been chosen for another element by someone else in their model. A good way to avoid this to prefix your new elements with short string that uniquely identify you or your company. So instead of me naming my class "MyClass" I should name it "MfpMyClass". You can think of this as poor-man's namespaces. This is a practice that is already widely used.
    2. You create an element that will be assigned an ID by the system, which already has been assigned to another element created by someone else in their model. Our plan is that this cannot occur once we ship AX6 - we are close to a full implementation of this, but we are not there yet. I'll return with more details on this at a later point.
    3. You customize an existing element that also has been customized by someone else in their model. There is really nothing you can do to avoid this collision, except to avoid customizing - which is not desirable nor possible. To alleviate this problem we are investing in changing the granularity of elements. In AX2009 tables and classes are stored with a fine granularity. This means that there is no collision if two models change two different methods on the same class or table. In AX6 all new concepts introduced in the model will also use a fine granularity - further we are breaking down some of the existing concepts, so far we have completed this work for Menus.

    So apparently we cannot guarantee that models can co-exist in the same layer - so what are the options when two models are in conflict? When you import a model that conflicts with an already imported model, you get three options:

    • Push-up (default)
      This option creates a new model in layer above containing the conflicting elements. This enables you to log into this layer and resolve the conflicts using the MorphX tools you are used to. Please notice that only the few elements in-conflict will be moved into this model, so the resolutions required are limited, and the original models will co-exist in the model store - but not only in the same layer.  

      For example; if two models ("ModelA" and "ModelB") are imported into the BUS layer, then "ModelA" is imported without any problems, and "ModelB" will be imported into two models: "ModelB" in the BUS layer, and "ModelB_Conflicts" in the BUP layer.
    • Overwrite
      This option will overwrite any existing definitions with the definitions in the new model. Any model containing element definitions that get overwritten will be logically grouped with new model. The grouping ensure that an eventual uninstall of a model doesn't leave the system in an in-complete state. This option is primary useful for patches that are accumulative in nature.

      For example; If a model "ModelA" containing PatchA is already installed, and a new model "ModelB" containing PatchA+B is being installed then this is the right option. Later; if "ModelB" is being uninstalled, then "ModelA" is also automatically uninstalled.
    • Abort
      This option aborts the operation and leaves the model store untouched - perhaps you specified the wrong model file, perhaps you want to investigate the models before continuing. 


    Models enable a lot of highly desirable scenarios, one of the most important scenarios being that models from different sources - for example, two ISVs - can be installed in the same layer side-by-side.  There are a few technical limitations; but the risk of conflicts is much reduced in AX6 and even when conflicts occur there is a less-expensive way to make the models co-exist.  

    More on models...

    This post is a part of a series on models:

    1. Deploying models
    2. Manifest and signing
    3. Multiple models per layer
    4. Working with models inside MorphX

    This posting is provided "AS IS" with no warranties, and confers no rights.

  • mfp's two cents

    Seeing is believing - AX 2012 X++ Editor


    Here is a sneak preview of the new X++ Editor in Microsoft Dynamics AX 2012.

    Notice that the editor now features word-completion, automatic indenting, scripting, zoom, multiline editing, and much much more.

    This post is also available on Channel 9.


  • mfp's two cents

    Seeing is believing - AX 2012 Developer Workspace


    Here is a sneak preview of the new MorphX developer workspace in Microsoft Dynamics AX 2012.

    Notice the clear distinction between developer and application workspaces, and how the layout of the drop down menus makes it possbile to access tools with fewer clicks. You can launch the AX client directly in development mode using: AX32.exe -development.

    This post is also available on Channel 9.


  • mfp's two cents

    The solution to the element ID problem


    About 3 years ago heading into the design phase of AX 2012 I wrote the Solving the element ID problem post. As the post describes element IDs in AX have constituted an inherent problem in all past AX releases. The problem is so fundamental that when I met with the original Axapta architects (at the Damgaard Data 25 years reunion party) they considered it insolvable without a major rewrite. In AX 2012 we did solve the problem. This post outlines the solution.

    Design pillars

    Before I dive into the solution these are our design pillars:

    1. Backward compatible. We cannot introduce any inconsistencies in business data or meta data.
    2. Minimal impact on customizations. The uptake of required changes must be minimal and easily absorbed when upgrading to AX 2012.
    3. Completed by AX 2012 RTM. We do not desire a staged multi-release solution to this problem.

    The solution part A - 32 bit IDs

    First we needed to break the upper limit of 60.000 IDs. We decided to make IDs 32 bit (used to be 16 bit). The primary deciding factor for int32 (and not int64 or guid or str) was that there would be no X++ uptake cost of using an int32, as the int data type in X++ already is a 32 bit integer - in other words all X++ code (and table fields) handling/containing IDs would simply just continue to work untouched. In the SYS layer we have >500 fields containing IDs. Not having to convert these (e.g. to GUIDs), and provide upgrade scripts is highly desirable. 

    As the ID for table fields already were 32 bit (16 bit for the element ID and 16 bit for the array index) we decided to keep the field IDs as is. In other words the element ID for fields are still just 16 bit. Given these are scoped by the table, there are no upper limit concerns involved here.

    Besides a lot of kernel refactoring there was one significant X++ impact. The intrinsic function TypeID had to be deprecated. It returned a 32 bit integer where the lower 16 bits contained the Type (either Types::Enum or Types:UserType), and the upper 16 bits the element ID. This function was primarily used in relation to the Dialog framework. The solutionwas to change the dialog framework to use the name of the type instead of the bit mangled integer.

    The solution part B - Installation specific IDs

    To solve the uniqueness problem, we need to ensure that two (or more) solutions can be implemented independently, and installed on the same system without any ID conflicts. In AX 2009 the assignment of IDs happens at creation time (i.e. when the element is created in the AOT). In AX 2012 we are deferring the assignment of IDs to installation time. This means that the model file containing the elements does not contain any element IDs. The IDs are being assigned when the model is imported by AxUtil. The consequence of this is that the same class will have different IDs on different installations. We call it "Installation specific IDs".

    Caution: Deleting a model and reimporting it (or a newer version of it) will randomize IDs and thus cause data integrity issues. The right procedure when upgrading a model is to not delete the model, but just import on top of the existing model.

    Given the requirement to be backwards compatible we must ensure that elements released in AX 2009 (and AX 4) retained their IDs. To satisfy this requirement we introduced a new int property on all ID based elements: LegacyID, and assigned it the ID value from past releases. Now we have captured the ID the element used to have in a simple (and editable) property, and we can use it during import.

    As it is vital that an element retain its ID across releases, we need to find a way to support rename scenarios. Consider the scenario where a new AX 2012 class is renamed in AX7. As the class is new it will have an installation specific ID; once the AX7 model is being imported we need to retain the ID - but if the only match criteria is the class name, and the class has been renamed, then we cannot fulfill the requirement. To solve this we introduced a new guid property on all ID based elements and all root-elements: Origin. This property is set when an element is created, and remains static for the lifetime of the elements. It is the element's fingerprint.  Besides enabling invariant IDs across releases for renamed elements the Origin property has proven valuable in data export scenarios, and rename scenarios of newly fine grained meta data (like forms). This will be covered by another blog post soon.

    AxUtil will during import assign IDs based on these rules:

    1. If an element already exists with the same Origin, then replace the element and reuse its ID - else
    2. If an element already exists with the same Type, Name and ParentID, then replace the element and reuse its ID - else
    3. If the import element has a Legacy ID, and the LegacyId is available on the target system, then add the element setting ID = LegacyID - else
    4. Assign a new installation specific ID from a guaranteed free range that will not collide with any LegacyIDs (>60000 for fields, >1000000 for all other elements)

    Notice: IDs are no longer tied to layers, e.g. Layers no longer have an ID range. Nor do you need the Team Server (aka. ID Server) anymore when using a version control system.

    Data can be exported from one installation to another. It is vital that any ID on the source system is mapped to the corresponding ID on the target system. The data import feature has been improved so all columns containing element IDs will be converted automatically (given they are using the proper extended data type). However; we also needed to address eventual IDs in blobs (containers). Data import and model import has no insights into the structure of the blobs. The only solution to this is to replace all ID-based element references in blobs with name-based references. We have done this for:

    • All kernel classes returning a container - e.g. Query.pack(), QueryRun.pack(), Map.pack(), Set.pack() etc.
    • All X++ classes packing element IDs (typically Runbase derived classes). A best practice rule is in place to detect these.
    • All references in meta data - e.g. when a form data source refers to a table.

    Wrapping up

    To solve the ID problem we had to introduce two new id properties - LegacyID and Origin. This may sound like a step in the wrong direction; however, the nature of these new properties are less restricting than that of the element ID property. In fact the only restriction on the new properties is that Origin must be unique - given Origin is a guid that is easy to satisfy. This restriction is enforced at the database level.  All in all the changes outline above has been a significant investment to solve this inherent problem in the least intrusive way possible. Yet it has an impact. My next blog post will describe the impact.

    The most important message is: If you are a new Microsoft Dynamics AX 2012 customer or partner, you do not need to worry (or care) about element IDs.

  • mfp's two cents

    New Layers in Dynamics AX 2009


    4 layers have been renamed in Dynamics AX 2009 . DIS / DIP / LOS / LOP have become HFX / SL1 / SL2 / SL3 respectively. HFX is reserved for releasing hot fixes, and the 3 new solution layers (SL1/SL2/SL3) will be used to release Microsoft Dynamics Industry Solutions.

    The purpose of having 3 solution layers is to enable side-by-side install of Industry Solutions. At deployment time any SL1 layer can be renamed to SL2, SL3, BUS or BUP through a regular file rename. The AOS will recognize the layer, and honor its position in the layer stack. This will enable installing up to 3 Industry Solutions on the same system (or up to 5 Industry Solutions if the BUS and BUP layers are vacant.)

    Another aspect of side-by-side installation is conflicting names and IDs in the model. The AX platform requires unique names and IDs of all model elements, we will ensure uniqueness across Industry Solutions through our engineering processes. Naturally there will be logically overlayering conflicts for certain elements; but as the Industry Solutions by nature are verticals we anticipate very few of these. These conflicts will need to be resolved; one way is to reclaim one of the SLx layers as an adaptation layer. More information on this will be available as the Industry Solutions become available.

    Why not just support an unlimited numbers of layers?

    Frequent feedback we get is to add more layers; and open them up for consumption by the partners. And heck, why we are at it why not have an unlimited number of layers?

    Currently; there is an upper limit on the number of layers the kernel can support. This number is 16. The technical explanation has to do with referencing of the elements in the model. Each model element is stored in a record in the AOD file. The RecId for model elements is a 32 bit integer. 4 of these bits denote the layer; the remaining 28 bits are used to calculate the offset into the AOD file where the record is located. In version 3.0 (and previously) the block size was 1 byte. This basically mean the maximum size of an AOD file is about 256MB (2^28). In version 4.0 we moved this limit by denoting one of the 28 bits to control the block size. When the bit is not set, the 27 bits is the direct offset in to the file. When the bit is set, a block size of 48 bytes is used to calculate the offset in the file. This enables AOD files with sizes up to about 6.5 GB (2^27 * 48), while enabling binary backwards compatibility with 3.0 AOD files (with sizes less than 128MB (2^27)).

    If we decide to use one bit more to denote the layer (giving us 32 layers); it means we are only backwards compatible with AOD files with sizes less than 64MB (2^26). As that is not acceptable; tools to align the contents in AOD files would be needed. For 6.0 we are investigating options to tear down these limitations once and for all.

Page 1 of 20 (195 items) 12345»