This document is a compilation of the fixes that are built into Microsoft
Dynamics AX 3.0 with Service Pack 6 (SP6). All issue numbers are bug
numbers that Microsoft and its partners can use to track these problems to
resolution. Microsoft Knowledge Base (KB) numbers, when they are available, are
linked to the published Knowledge Base on Partner Source (you must have access
to Partner Source to access these links).
This document contains information
similar to what can be found in the Microsoft Knowledge Base for a customer fix request
escalation. Because some Microsoft Knowledge Base articles for these fixes are
not yet published, this information is only as complete and accurate as is
currently possible.
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description |
| #2384 | Not available | The incorrect value was selected when a custom table lookup form was open for a string editing controls. | • Problem The incorrect value was selected when a custom table lookup form was open for a string editing controls. When the current value of the string edit control was read in the SysTableLookup::formRun method, the text method was used. If the user did not modify the value of the bound control, this method returned an empty string. • Solution The necessary modifications have been made to make the custom lookup code read current values for such controls too. In particular, the valueStr method is used if the user does not modify the value of the control. |
\Classes\SysTableLookup |
| #3964 | KB900816 | The values of the lookup controls for the option button and check box controls were not read correctly on Web forms. | • Problem The values of the lookup controls for the option button and check box controls were not read correctly on Web forms. The issue occurred because the values of the lookup controls were accessed by using JavaScript code, which gives no result for option buttons and check boxes. • Solution The additional JavaScript code is used on Web forms to read the values of the option button and check box controls. |
\Classes\WebFormHtml |
| #5848 | Not available | When, in the Query dialog box, the user deleted a data source that had child data sources and then created the same data sources, the child data sources became invisible. | • Problem When, in the Query dialog box, the user deleted a data source that had child data sources and then created the same data sources, the child data sources became invisible. The issue occurred because the data sources and internal variables that stored information about data sources represented by a GUI object became unsynchronized. This occurred after the user added the Data source node by using the shortcut menu. When the user deleted a previously added data source, the data source was not actually deleted, but its Enabled property was set to FALSE. Disabled data sources were not shown in a GUI object. Also, a disabled data source could have child data sources. Therefore, when the user created a data source that had been previously deleted, the data source’s Enabled property was set to TRUE again and it was added to a GUI object. But its child data sources, if any, were not shown in a GUI object. • Solution After the user adds a new data source, Microsoft Dynamics AX determines whether this data source has any child data sources and rebuilds a GUI object that represents the query data sources. |
\Classes\SysQueryForm |
| #6914 | Not available | In several locations in Microsoft Dynamics AX, zero-based arrays were treated as one-based. | • Problem In several locations in Microsoft Dynamics AX, zero-based arrays were treated as one-based. Usually, arrays in X++ are one-based. This means, that items in an array are numbered ‘1’, ‘2’, ‘3’ and so on. The number of the last item is equal to the number of items in the array. Nevertheless, there are few exceptions from this rule. There are few zero-based arrays with items numbered ‘0’, ‘1’, ‘2’ and so on. In particular, this is the case with some routines working with enumerations. However, in some locations enumeration indexes were treated as one-based. • Solution The enumeration indexes usage has been changed. The first item of the enumeration is referenced as item ‘0’, the next one is item ‘1’ and so on. |
\Data Dictionary\Maps\HRMPersonNameMap\Methods\setSalutation \Data Dictionary\Maps\HRMPersonNameMap\Methods\setNameSuffix \Classes\BMInitDatabase\initSetup \Data Dictionary\Tables\EPDocuParameters\Methods\initValue \Classes\EPSetupWizard\fillDocumentTree \Classes\Global\pickEnumValue \Classes\BMTestScope\runAll |
| #9026 | Not available | Orphaned records were left in the SysSecurityFormControlTable table when the user group security settings were changed. | • Problem Orphaned records (those unused by Microsoft Dynamics AX and not related to other records) were left in the SysSecurityFormControlTable table when the user group security settings were changed. This issue occurred because there was no DeleteAction specified on SysSecurityFormTable for SysSecurityFormControlTable. Therefore, it was possible to delete a record in SysSecurityFormTable without deleting the corresponding records in SysSecurityFormControlTable. • Solution DeleteAction has been created on SysSecurityFormTable for SysSecurityFormControlTable. |
\Data Dictionary\Tables\SysSecurityFormTable |
| #10999 | Not available | Ranges were sometimes applied incorrectly in queries used as data sources for OLAP cubes. | • Problem Ranges were sometimes applied incorrectly in queries used as data sources for OLAP cubes. In particular, ranges for date-typed fields did not work correctly. When generating the SQL WHERE clause in the kernel, input value strings (in Microsoft Dynamics AX format) were put as is into the output string (which should be in SQL language). Because the Microsoft Dynamics AX date format is invalid in SQL language, the OLAP data source view could not be created. A workaround present in the OLAPCreateSchema\createDatasourceView X++ method offsets this issue somewhat by putting values into quotation marks, but this did not work for date-typed fields and for complex ranges. • Solution The valid SQL literals for Microsoft Dynamics AX values is generated in the kernel. Also, the workaround in the OLAPCreateSchema\createDatasourceView X++ method has been removed, because it is not needed any longer. The query generated by the kernel is put into brackets so that this workaround does not try to add quotation marks symbols itself. In this manner, kernels that have this fix implemented would work regardless of the implementation of the X++ part of this fix. |
Qeimisc.hpp Qenode.cpp \Classes\OLAPCreateSchema\createDatasourceView |
| #11714 | Not available | Each time that the custom lookup using the SysTableLookup class was activated, the form with the same name as the table that was used in the lookup lost its user settings. | • Problem Each time that the custom lookup using the SysTableLookup class was activated, the form with the same name as the table that was used in the lookup lost its user settings. In the \Classes\SysTableLookup\formRun method, the constructed custom lookup form was given the same name as the lookup table. If a form with the same name was used, user settings were overwritten. • Solution The "TemporaryFormName" name is used for the custom lookup form in the \Classes\SysTableLookup\formRun method. Therefore, the form settings are not saved for the constructed lookup form, because the \Classes\SysSaveSetup\valid method returns FALSE for it. |
\Classes\SysTableLookup |
| #12066 | Not available | An error occurred if the user tried to perform a comparison in the Import dialog box when importing elements to the Application Documentation node. | • Problem An error occurred if the user tried to perform a comparison in the Import dialog box when importing elements to the Application Documentation node. The issue occurred because, in the \Classes\SysImportElements\buildTreeContextMenu method, a call to the infolog.getImportedNode(…) method returned NULL for documentation nodes. • Solution The \Classes\SysImportElements\buildTreeContextMenu method has been modified for the correct handling of documentation nodes. Necessary changes have been made in the kernel for handling comparison of documentation nodes. |
\Classes\SysImportElements DOCNODE.cpp |
| #12649 | Not available | In some cases, if a property of an object contained a string that was the same as the name of another property of that object, the output of the Global::setProperty X++ method was invalid. | • Problem In some cases, if a property of an object contained a string that was the same as the name of another property of that object, the output of the Global::setProperty X++ method was invalid. If an attempt was made to modify an array property that used the same method, the output was also invalid. To find the location of the property within the property set string, a simple string scan for the property name was used. If a string contained a property name as a part of the data of any previous property, the routine produced an invalid output. The algorithm of the property modification was overly simplified and in some cases determined the location of the property inside the set string of the property incorrectly. • Solution The algorithm of the property modification has been improved. |
\Classes\Global |
| #12652 | Not available | The selection feature in the Look in field of the Find dialog box did not work. | • Problem The selection feature in the Look in field of the Find dialog box did not work. It was not possible to specify the location of a search in the AOT when the Find dialog box was already open. The issue occurred because the search criteria that was specified in the Look in field was ignored. • Solution An assignment statement is added to the root search node immediately before the user runs the search. The search node is taken from the Look in field. |
\Forms\SysAOTFind |