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 |
| #7697 | Not available | The Item arrival branch (Inventory management > Journals > Item arrival) enclosed itself on the Permissions tab of the User group permissions form. | • Problem The Item arrival branch (Inventory management > Journals > Item arrival) enclosed itself on the Permissions tab of the User group permissions form (Administration > Setup > User groups). Therefore, when the user expanded the Item arrival branch, one more Item arrival was enclosed. When, in the User group permissions form, Microsoft Dynamics AX showed a display menu that corresponded to a security key, it searched the menu item buttons on the linked form and added the corresponding items as children of the original display menu in the permissions tree. These child items can also be expanded to set access on corresponding objects. Therefore, when the display menu was linked to a form that consisted of a menu button linked to a display menu item linked to the original form, users expanded the corresponding item in the tree they would receive this item continuously. For \Menu Items\Display\WMSJournalReception, it pointed to \Forms\WMSJournalTable, which consisted of a menu button that was linked to a display menu. Therefore, it opened another instance of this form - \Menu Items\Display\WMSJournalReception. • Solution In the \Classes\SysSecurity\expandFormMenuItems method that expands menu items in the permissions tree, child items will not be added if they were previously loaded by some parents in this tree. Only direct parent nodes are checked; their child items are not checked. Therefore, an endless cycle when a form has a reference to itself is avoided. |
\Classes\SysSecurity |
| #7919 | KB900712 | Security settings denying write access for the table did not prevent data update if the Microsoft Office Excel template was used for data import. | • Problem When importing data by using the Microsoft Office Excel template, the data was updated even if the security settings for the table denied write access. The SysdataImportExcelServer::sheet2Table method has the code inserting records to the tables. The issue occurred because this method did not check if the update was forbidden for a table. • Solution The code checking the appropriate rights has been added to the SysdataImportExcelServer::sheet2Table method. |
\Classes\SysDataExpImpBase \Classes\SysDataImportExcelserver |
| #8856 | Not available | The "License value for ‘ID XX’ has not been created." Infolog messages appeared after importing a new license file. | • Problem The "License value for ‘ID XX’ has not been created." Infolog messages appeared after importing a new license file. These warnings occurred because of outdated license values that were still in a license file, but were not used any longer in the application. The existence of license values was confirmed by checking whether the creation of DictLicenseCode succeeds before they were created in the database. When the system read a license file all values described in that file are being updated in the database. This resulted in a warning that the License value for a specific ID did not exist when this value could not be updated. • Solution A check on the creation of SysDictLicenseCode has been added in the setCode method. The check runs before the database is updated. This prevents warnings for nonexistent license values from appearing. |
\Classes\SysLicenseCodeReadFile |
| #8969 | Not available | An error occurred when the user tried to create an Office Excel template by using the Excel Spreadsheet Template Wizard, if the target table consisted of fields based on the standard data types. | • Problem An error occurred when the user tried to create an Office Excel template by using the Excel Spreadsheet Template Wizard, if the target table consisted of fields based on the standard data types (integer, string and so on). The issue occurred because, in the \Classes\SysExcelTemplateWizard\formatCell method, the DictEnum object variable was used without checking if it was initialized (not NULL). • Solution Additional checks have been implemented to avoid using objects that are not initialized. |
\Classes\SysExcelTemplateWizard |
| #9072 | KB901121 | When users tried to set a Record Level Security restriction against the dimension in the Record Level Security Query form, they experienced problems with selecting dimension values in the Range field because the Dimensions lookup was always filtered by dimensions of the ‘Department’ dimension type only. | • Problem When users tried to set a Record Level Security restriction against the dimension in the Record Level Security Query form, they experienced problems with selecting dimension values in the Range field because the Dimensions lookup was always filtered by dimensions of the ‘Department’ dimension type only. The Query form did not have much information about the table it was going to show the lookup for. Therefore, it used the default lookup for that table. For the Dimensions table, this choice was not good enough because the default Dimensions lookup was always filtered by the dimension type. When no suitable information about the required filter was obtained, it showed only dimensions of the very first type, the ‘Department’ type. Originally, the DimensionsLookup form worked in two different modes. The first was the ‘All’ mode, when the lookup showed all records of the specified dimension type. The second was the ‘selectable’ mode, when additional filtering was applied to records of the specified dimension type. By default, the ‘All’ mode with the ‘Department’ dimension type was used. • Solution An additional lookup mode called the ‘Plain’ mode has been introduced. In this mode the DimensionsLookup form displays all existing dimension records. The lookup switches to this mode only if it is called from the Query form. |
\Forms\DimensionsLookup |
| #10654 | Not available | Modifications of the selection criteria for the Users online time report were processed incorrectly. | • Problem Modifications of the selection criteria for the Users online time report were processed incorrectly. The issue was caused by assigning a newly created QueryRun object to the QueryRun variable of the ReportRun class and passing this variable to the RunBaseReport class afterward. All the user modifications that were made to the query were done on the ReportRun Query variable. However, when the report was executed, the ReportRun.QueryRun.Query() object was used. At first these two query objects were referenced to one query, but after creating a new QueryRun object the ReportRun.QueryRun.query was different from ReportRun.query. Therefore, all user modifications were lost. • Solution The segment of code that created the new QueryRun object for the report has been removed. |
\Reports\SysUsersOnline |
| #14062 | Not available | There was no way to forbid form customization in Microsoft Dynamics AX 3.0. | • Problem There was no way to forbid form customization in Microsoft Dynamics AX 3.0. The issue occurred because the system only had a configuration key that allowed or forbade advanced form customization. However, the code to prohibit basic form customization was missing. • Solution A new configuration key and its support have been added to Microsoft Dynamics AX 3.0. This key implements a global approach to allow or forbid basic form customization, such as hiding or showing form controls, changing labels, and so on. |
\Classes\SysSetupForm \Forms\SysSetupForm FORMRV.cpp classes.hpp forcommn.cpp FORMC.cpp |
| #16986 | Not available | The user was unable to view the Production and Questionnaire menus in the Main menu even if permissions to access items in these menus were previously set up. | • Problem The user was unable to view the Production and Questionnaire menus in the Main menu even if permissions to access items in these menus were previously set up. The issue occurred because some menus that were included in the Main menu had a security key set that was not needed. These menus should have only had a configuration key. These menus stayed inaccessible because the user did not set up a corresponding security key for them. • Solution The unnecessary security key has been removed from the Production and Questionnaire menus in the Main menu. |
\Menus\Prod \Menus\KMQuestionnaire |
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description |
| #3981 | Not available | A document reference record was created in the Document handling form even if the document file could not be created. | • Problem A document reference record was created in the Document handling form even if the document file could not be created. When a file-based document (for example, a Microsoft Office Word document) was created, a reference record was created and saved in the database. After the document file was created, this reference record was updated with the corresponding file name. However, if the file could not be created, that reference was left in the database an had no file linked to it. • Solution A document reference record is still inserted into the database before creating a document file, but if that file cannot be created, that record is deleted. To implement this change, the DocuAction class has been modified: if the DocuAction object cannot be initialized or an error occurs when the user creates the new document, the inserted reference record is deleted. Also, no error message appeared if the DocuAction object could not be created or if users closed the Attach file dialog box when they created a document. To make the new error handler work in these cases, the "The document cannot be inserted." error message is shown. Finally, the CatchAllAndRethrow macro has been added to help in creating error handlers. |
\Classes\DocuAction \Classes\DocuActionArchive \Macros\CatchAllAndRethrow |
| #4931 | Not available | An error occurred when the user opened a file in the Document handling form while the same file was being previewed. | • Problem An error occurred when the user opened a file in the Document handling form while the same file was being previewed. The issue occurred because the file being previewed was locked and therefore an error occurred when the user tried to open the same file by using the Open button in the Document handling form. • Solution Allow for the opening program to open the already opened file. Depending on the opening program (Word, Excel and so on), the program behaves appropriately. |
\Classes\DocuActionFile \Classes\WinAPI |
| #7312 | Not available | The ‘All level’ dimension level was created in the OLAP cube regardless of the state of the All level check box. | • Problem For a dimension in the OLAP cube, it should be possible to specify if an ‘All Level’ should be created or not. An ‘All Level’ creates a level that holds the grand total for the dimension. However, changing this option in Microsoft Dynamics AX did not have any influence on how the dimension was created. ‘All level’ was always created. The issue occurred because the check to see whether the option was set contained mistake in the code. • Solution The check code has been corrected. This lets the user create the ‘All Level’ only when the All Level check box is selected for a dimension. |
\Classes\OLAPTransferMetaData |
| #8150 | Not available | The special characters of the Czech language were not printed when printing to a document in the PDF format. | • Problem The special characters of the Czech language were not printed when printing to a document in the PDF format. The issue occurred because standard code page 1250 was used in this case. • Solution Because most of the Czech characters are not supported by the standard PDF printing engine, TrueType font indexes are used to write characters to a PDF document. Therefore, the TrueType font is declared for the PDF sections and the actual text is written in the font index numbers instead of the characters themselves. |
\Data Dictionary\Classes\SysPDFFontType2 \Data Dictionary\Classes\SysPDFFont \Data Dictionary\Classes\SysPDFFontTypeUnicode \Data Dictionary\Classes\PDFViewer |
| #8681 | Not available | Data was processed partly or was not processed at all when multiple time dimensions that use different time fields were present in the OLAP cube. | • Problem Data was processed partly or was not processed at all when multiple time dimensions that use different time fields were present in the OLAP cube. When multiple time dimensions were present in the OLAP cube, only one data source table that contained dates was created together with several relations from different fields to it. Therefore, the data was not processed unless the dates used for dimensions were the same. • Solution To resolve this issue, several separate data source tables have been created that have one relation to each for each time dimension. Therefore, a correct OLAP cube data source structure is created. |
\Data Dictionary\Tables\OLAPCubeInstance \Data Dictionary\Tables\OLAPTimeLev \Macros\OLAPConstants \Classes\OLAPCreateSchema \Classes\OLAPDimension \Classes\OLAPDimensionMetaData \Classes\OLAPFactory \Classes\OLAPLevelMetaData |
| #12187 | Not available | If a name of the document handling archive directory consisted of only one symbol, newly created documents were saved not in that directory, but in its parent. Additionally, a letter of the name of the archive directory was added to the beginning of the file name. | • Problem If a name of the document handling archive directory consisted of only one symbol, newly created documents were saved not in that directory, but in its parent. Additionally, a letter of the name of the archive directory was added to the beginning of the file name. Also, the name of the archive directory and the file were concatenated, because the explicit check for the backslash at the end of an archive path was not performed in every situation. The standard file path handling routine (Docu::fileCheckPath) contained a mistake in the code that prevented it from adding a slash to the end of the path if the path’s last folder name was one symbol long. • Solution Additional checks have been added to make sure that the archive path will always have a backslash at the end. A standard file path handling routine is used instead of the custom method that duplicated this functionality. The standard file path handling routine has been improved to handle one-letter folder names correctly. |
\Data Dictionary\Tables\DocuRef \Classes\Docu |
| #13539 | Not available | The Microsoft Dynamics AX client stopped responding if the resulting customer address was an empty string or a string that contained only spaces. | • Problem The Microsoft Dynamics AX client stopped responding if the resulting customer address was an empty string or a string that contained only spaces. In the \Data Dictionary\Tables\Address\Methods\formatAddress method address data was formatted and combined with the actual address contents. The resulting string was a multiline string that was used later in the application. After the string generation deleted the spaces, new lines at the end of the string were deleted. In one of these cycles Microsoft Dynamics AX client stopped responding. A mistake in the X++ address formatting logic was causing an endless loop, which caused the client to stop responding. • Solution The exit condition of both cycles has been changed to make sure a graceful exit from the cycle if the string becomes empty during the processing. |
\Data Dictionary\Tables\Address\Methods\formatAddress |
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description |
| #1978 | Not available | The Enterprise Portal did not show the correct list of selected items based on the WebLet category selection if the data type that was used for filtering was array. | • Problem The Enterprise Portal did not show the correct list of selected items based on the WebLet category selection if the array data type was used for filtering. The issue occurred because the WebCatBrowseWeblet::buildCategoryList() method that used the call to relationObject() without specifying the array order (default was ‘1’). • Solution An argument that defines the array order has been added to the relationObject() call. |
\Classes\WebCatBrowseWeblet |
| #6940 | Not available | An error occurred when the user were creating the Virtual Directory on Windows 2000 Server when ‘0’ was passed as an index in httpErrorsArray. | • Problem An error occurred when the user were creating the Virtual Directory on Windows 2000 Server because of a typographical mistake when ‘0’ was passed as an index in httpErrorsArray. The issue occurred because the WebSiteTable\createVirtualDirectory method used httpErrorsArray.lastindex(), which was always equal to ‘0’, as if it was just created. • Solution Modifications have been made to use ‘1’ as an index constant. |
\Data Dictionary\Tables\WebSiteTable\Methods\createVirtualDirectory |
| #8857 | Not available | In the Enterprise Portal, number of the blanket order was by mistake specified also as the number of the release order. | • Problem In the Enterprise Portal, the number of the blanket order was incorrectly specified also as the number of the release order. The issue occurred because of a mistake in the design of the Web form. • Solution The Web form for the Sales order form has been redesigned. After the redesign the ID of the release order is displayed in the list for the blanket order. If the user clicks the ID, the corresponding release order is displayed. |
\Web\Web Forms\EPSalesTableInfo |
| #9013 | Not available | Sometimes a record added to a grid in a Web form was not visible. | • Problem Sometimes a record added to a grid in a Web form was not visible. The issue occurred because a new record was added after the current record, which means that it would not appear on the current grid page in some cases. • Solution The code has been corrected to insert a new record after the last visible row of the grid page. |
\Classes\WebFormHtml |
| #9168 | Not available | The contact person E-mail lookup in the Documents sending Web form contained all contact persons instead of only logged on vendor contact persons. | • Problem When the contact person E-mail lookup was activated by a vendor user in the Enterprise Portal Documents sending Web form, all contact persons were displayed, though only the contact persons for the logged-on vendor should be displayed. The issue occurred because in the lookup method of the EmailAddress Web control in the EPSendDocument Web form, the lookup method for the customer’s contact persons (ContactPerson::webLookupCustContactPerson) was called using the parmAccountNumber customer account as a parameter. For vendors, parmAccountNumber was empty, and the customer contact persons lookup method showed all contact persons. • Solution The lookup method for vendor contact persons is called when the Documents sending Web form is created for a vendor. When parmVendAccountNum is not empty, the ContactPerson::webLookupVendContactPerson method is called instead of the ContactPerson::webLookupCustContactPerson method. |
\Web\Web Forms\EPSendDocument |
| #10660 | Not available | The form that displays statistics for a project in the Enterprise Portal was always empty. | • Problem The form that displays statistics for a project in the Enterprise Portal was always empty. The issue occurred because of a typographical error. The project ID parameter was set instead of the employee ID. Therefore, the project did not exist and the Statistics form was empty. • Solution The code has been modified so that the correct parameter is now passed to the Statistics form. The display method that calculates the Contribution ratio and Contribution margin has been modified to display the correct data. |
\Web\Web Forms\EPProjStatistic |
| #17276 | Not available | The Enterprise Portal Web site did not create a document handling URL as ‘https’ when SSL was enabled. | • Problem The Enterprise Portal Web site did not create a document handling URL as ‘https’ when SSL was enabled. The issue occurred because the method that makes up the document URL contained a hard-coded ‘http’ protocol. • Solution The code has been modified so that when SSL is enabled in the properties of the Enterprise Portal Web site, and the server running IIS has SSL support enabled, the document URL uses the ‘https’ protocol. |
\Classes\EPSendDocument |
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description |
| #11073 | KB907872 | An incorrect previous value was shown on the History tab of the Database log form for update transactions made at the same time. | • Problem An incorrect previous value was shown on the History tab of the Database log form (Administration > Inquiries > Database log) for update transactions made at the same time (with the same modification time). This issue occurred because the database log records created at the same time were not distinguished when the information was displayed in the Database log form. • Solution The code has been modified to distinguish database log records created at the same time using their record IDs. |
\Forms\SysDatabaseLog |
| Request No. | KB Article No. | Short Description | Detailed Description | Object Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #742 | Not available | A database error occurred when the user tried to transfer OLAP cubes if OLAP was used in several schemas of the same Oracle database. | • Problem The "Table or view does not exist" database error ORA-00942 occurred when the user tried to transfer OLAP cubes if OLAP was used in several schemas of the same Oracle database. The error occurred because the cube update routine could not handle the situation when views with the same name existed in several schemas. • Solution The code has been modified so that only the names of the views in the current database scheme is selected now. A range on the OWNER column has been added to the generated database query. |
\Classes\SQLBuilderView | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1552 | Not available | No form control permissions were exported while exporting user group permissions. | • Problem No form control permissions were exported while exporting user group permissions. Therefore, when users imported permissions, only some of the permissions were imported. The issue occurred because of a mistake in the user group permissions routine. • Solution The user group permissions routine has been changed to include form control permissions in the export operation. |
\Classes\SysSecurityUserGroup \Classes\SysSecurityFormSetup | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3035 | Not available | When using the code upgrade tool in the AOT from the Add-ins menu for Reports and Forms, the labels of different layers did not appear on the tab pages. | • Problem When using the code upgrade tool in the AOT from the Add-ins menu for Reports and Forms, the labels of different layers did not appear on the tab pages. Also, the code shown for different layers was incorrect. When the shortcut menu was built for an object in the AOT, the menu items available are based on the object type. No check was made for the menu item for the upgrade tool. Therefore, the upgrade tool was available, by mistake, for all types of objects in the AOT. • Solution A check has been added to make the Code upgrade tool available only for Tables, Table methods, Classes, and Class methods. |
\Classes\SysContextMenu | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3901 | Not available | When the user printed Infologs, the generated report contained double the pages as the same report when the user printed from Microsoft Axapta 2.5. | • Problem When the user printed Infologs, the generated report contained double the pages as the same report when the user printed from Microsoft Axapta 2.5. The image that was used in the report to illustrate if an Infolog message was a warning, information or an error was not initialized correctly. Therefore the report contained a too large "blank" image for each line making each line the height of the blank image. The issue occurred because the sysInfoLog report in Microsoft Dynamics AX 3.0 had an error in the Bitmap method that never initialized the image control. • Solution The Bitmap method has been modified to make it correctly initialize the image and set the height of the bitmap to a fixed value. |
\Reports\SysInfoLog | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #3908 | Not available | All record templates for the selected table were deleted if the user wanted to delete a particular template immediately after reviewing it. | • Problem All record templates for the selected table were deleted if the user wanted to delete a particular template immediately after reviewing it. When the user clicks the Delete record button, Microsoft Dynamics AX tries to delete the operation on the data source that was linked to the active form control. If the control was not linked to any data source the main form data source was affected. However, when the user clicked the Edit button (it was a command button not linked to any data source) to run a form with a template, this button became an active form control. Therefore, the delete record functionality deleted a record not from the data source that had a template for the selected table, but from the data source that contained records indicating that the particular table had templates (it was the main form data source). Therefore, all templates for the table were deleted automatically. • Solution The code in the Record template form has been modified to make sure that only one template is deleted when it was necessary. |
\Forms\SysRecordTemplateTable | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4009 | Not available | It was not possible to view the used query in the Query Editor form when sales orders update jobs with the late selection were used. | • Problem It was not possible to view the used query in the Query Editor form when sales orders update jobs with the late selection were used. The issue occurred because the query to be displayed was reinitialized in the \Classes\SalesFormLetter\updateQueryBuild method each time that the Query Editor form was opened. • Solution The code has been modified to use the saved last selection query in the \Classes\SalesFormLetter\updateQueryBuild method. |
\Classes\SalesFormLetter | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4247 | Not available | Some tables and table fields that must be deleted after the upgrade from Microsoft Axapta 2.5 to Microsoft Dynamics AX 3.0 were not deleted from the database. | • Problem Some tables and table fields that must be deleted after the upgrade from Microsoft Axapta 2.5 to Microsoft Dynamics AX 3.0 were not deleted from the database. The issue occurred because the SysDeletedObjects30 configuration key was not set for the following tables and table fields:
• Solution The configuration key has been set to ‘SysDeletedObjects30’ for the tables and table fields listed above. |
\Data Dictionary\Tables\DEL_ProjItemReq \Data Dictionary\Tables\DEL_ProjlValidateGroupEmpl \Data Dictionary\Tables\DEL_smmTmpNumberSeqCreate \Data Dictionary\Tables\DEL_SysApplObjectArchive \Data Dictionary\Tables\DEL_TmpReqExplosion \Data Dictionary\Tables\Address \Data Dictionary\Tables\AddressFormatLines \Data Dictionary\Tables\BankChequeLayout \Data Dictionary\Tables\BMPerfResult \Data Dictionary\Tables\ContactPerson \Data Dictionary\Tables\CustLedger \Data Dictionary\Tables\CustPaymManStepPosting \Data Dictionary\Tables\InventModelGroup \Data Dictionary\Tables\InventTrans \Data Dictionary\Tables\LedgerTable \Data Dictionary\Tables\OLAPAmount \Data Dictionary\Tables\OLAPSetup \Data Dictionary\Tables\ProdJournalProd \Data Dictionary\Tables\ProdJournalRoute \Data Dictionary\Tables\ProdParameters \Data Dictionary\Tables\ProdParmHistoricalCost \Data Dictionary\Tables\ProjCategory \Data Dictionary\Tables\ProjGroup \Data Dictionary\Tables\ProjHourSalesPrice \Data Dictionary\Tables\ProjItemTrans \Data Dictionary\Tables\ProjItemTransCost \Data Dictionary\Tables\ProjJournalTrans \Data Dictionary\Tables\ProjParameters \Data Dictionary\Tables\ProjTransPosting \Data Dictionary\Tables\ReqGroup \Data Dictionary\Tables\ReqLog \Data Dictionary\Tables\SysCodeProfilerMethodSum \Data Dictionary\Tables\SysExpImpGroup \Data Dictionary\Tables\SysLabelLog \Data Dictionary\Tables\VendBankAccount \Data Dictionary\Tables\BMComputerTable \Data Dictionary\Tables\BMMachineModelTable \Data Dictionary\Tables\BMRunTable \Data Dictionary\Tables\CustPackingSlipJour \Data Dictionary\Tables\CustPackingSlipTrans \Data Dictionary\Tables\EUSalesList \Data Dictionary\Tables\MailMessages \Data Dictionary\Tables\ProdParmScheduling \Data Dictionary\Tables\ProjProposalItem \Data Dictionary\Tables\TmpReqExplosionOnHand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4925 | Not available | Under certain conditions if the user deleted a reference to document "A" stored in the database, he or she was not able to open any document stored in the database from this user account until all references to document "A" were deleted. | • Problem Under certain conditions if the user deleted a reference to document "A" stored in the database, he or she was not able to open any document stored in the database from this user account until all references to document "A" were deleted. This issue was caused by records with information about open files staying in the database when the corresponding document references had already been deleted. • Solution A relation has been created between the DocuOpenFile and DocuRef tables, and a cascade delete action has been added to the DocuRef table to delete the related DocuOpenFile records. |
\Data Dictionary\Tables\DocuOpenFile \Data Dictionary\Tables\DocuRef | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4926 | Not available | The Document handling form was not properly updated when the current record was changed in the corresponding Sales order or Purchase order form. This caused an incorrect state for the New button in the Document handling form. | • Problem The Document handling form was not properly updated when the current record was changed in the corresponding Sales order or Purchase order form. This caused an incorrect state for the New button in the Document handling form. The issue occurred because of the incorrect order of calls in the Active() method overriding data source of the Sales order or Purchase order form. The Enabled/Disabled status was set after the call to super(), which actually updates the dependent Document handling form. • Solution Modifications have been made to set the Enabled/Disabled status before updating the current record for the dependent Document handling form. |
\Forms\SalesTable\Data
Sources\SalesTable\Active() \Forms\PurchTable\Data Sources\PurchTable\Active() | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4927 | Not available | It was possible to create new documents for already posted entities when using the Document handling functionality. | • Problem It was possible to create new documents for already posted entities when using the Document handling functionality. The issue occurred because the Paste menu item in the DocuView form was enabled regardless of the ‘Posted’ status of the data source. • Solution A check has been added to the DocuView form that verifies whether the data source has the ‘Posted’ status and, if yes, disables the Paste menu item. |
\Forms\DocuView\setEnabled \Forms\DocuView\BeginEndLink\clicked | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4928 | Not available | An invalid document was created if the user created the document, copied it, deleted it, and then pasted it back. | • Problem An invalid document was created if the user created the document, copied it, deleted it, and then pasted it back. As a result, the document did not have some necessary fields filled in and could not be opened. The issue occurred because the copy functionality in the form did not use Windows clipboard, but filled an internal variable with the ID of the copied record. Therefore, errors occurred when the user tried to paste a record with an already deleted source. • Solution To prevent the user from pasting a deleted record, additional verification has been implemented in the delete method of the data source. Therefore, if a record being deleted is the one currently selected as a source for further paste operations, then the copied document id variable is set to ‘zero’ to indicate that no records have been copied. Later, when the delete operation finishes, the ‘Function’ buttons (including Copy, Paste, and Paste to all buttons) get reenabled. This disables the Paste and Paste to all buttons if the copied record has been deleted. |
\Forms\DocuView | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4929 | Not available | When the user used the Paste to all functionality in the Document handling form, the last selected item was not affected. | • Problem When the user used the Paste to all functionality (Functions > Paste to all) in the Document handling form, the last selected item (the last by selecting order, not by place in a table) was not affected. In the \Forms\DocuView\Methods\doReSearch method, when Microsoft Dynamics AX 3.0 filled the map used in later processing, there was a check that did not allow adding a record if it was an active record in a form linked to the Document handling form. • Solution The check that did not allow adding record to the intermediate variable map has been removed. Instead, in the \Data Dictionary\Tables\DocuRef\Methods\multiSelectRecordCreate method, a check that does not allow creating a new document when a source document is linked to a record has been added. This check prevents from creating a duplicate document. |
\Data Dictionary\Tables\DocuRef \Forms\DocuView | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4930 | Not available | In the Document handling form, the Open button was not disabled when all records were deleted. | • Problem In the Document handling form, the Open button was not disabled when all records were deleted. The issue occurred because the setEnabled() method was never called when deleting records. • Solution A call to the setEnabled() method has been added to the delete() method on the data source. |
\Forms\DocuView | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4932 | Not available | When the user closed the Document handling form, no dialog box requiring a confirmation for modifications appeared and user’s modifications were not saved. | • Problem When the user closed the Document handling form, no dialog box requiring a confirmation of the modifications appeared and the user’s modifications were not saved. The issue occurred because Microsoft Browser ActiveX control used to display documents, uses the application message queue for its work. When the user clicked the Close button in the title bar to close the form, the form’s WM_CLOSE message appeared in the queue prior to the browser control’s Ask for confirmation custom message. When the WM_CLOSE message was processed, the window was closed and disposed of along with the window controls, therefore the browser control had been disposed of before it processed its messages. • Solution The canClose method of the form has been overridden. The new implementation of the method processes all the browser control’s messages after performing the usual canClose functionality. |
\Forms\DocuView | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4933 | Not available | When records were deleted from most of the tables, document references linked to these records were left orphaned in the database. | • Problem When records were deleted from most of the tables, document references linked to these records were left orphaned in the database. There was no way to see or delete these references except by using the Table browser. Usually, when a record was deleted, delete actions are used to determine which other records should be deleted along with it. However, most of the tables did not have the delete actions set up for the DocuRef table, and document references were kept for the deleted records. • Solution The database consistency check job has been added to the report and optionally delete orphaned records in the DocuRef table. |
\Classes\docuConsistencyCheck | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4934 | Not available | No new document was displayed in the Document handling form for items of ‘table2’ if the user copied a document linked to ‘table1’ and then, in the Document handling form, used the Paste to all functionality (Functions > Paste to all) for items of ‘table2’. | • Problem No new document was displayed in the Document handling form for items of ‘table2’ if the user copied a document linked to ‘table1’ and then, in the Document handling form, used the Paste to all functionality (Functions > Paste to all) for items of ‘table2’. The issue occurred because the RefTableId field of the previously copied document was used when a new record was created without taking into consideration that the table linked to the Document handling form could change. • Solution An additional argument with the tableID of the current table has been added to the function that creates a new document. |
\Data Dictionary\Tables\DocuRef \Forms\DocuView | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #4936 | Not available | Sometimes an Excel dialog box appeared when the user worked with an Excel document that was opened from a form in Microsoft Dynamics AX 3.0 (using the Show file functionality). | • Problem Sometimes an Excel dialog box appeared when the user worked with an Excel document that was opened from a form in Microsoft Dynamics AX 3.0 (using the Show file functionality). The issue occurred because the WebBrowser ActiveX control was unable to handle the loading of another document correctly when a cell in an Excel document was being edited. • Solution The document editing function has been disabled for the Document handling form. |
\Forms\DocuView | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #5174 | Not available | In the Batch list form, it was not possible to change the status of the batch job and an error message was displayed. | • Problem In the Batch list form, it was not possible to change the status of the batch job and the "Error executing code: FormRun object does not have method ‘doReselect’" error message was displayed though this functionality worked correctly in Microsoft Axapta 2.5. In Microsoft Axapta 2.5, after the BatchChangeStatus class was processed, it called the executeQuery method for the form it was called from. To do this, it used the standard reSearch data source method. Microsoft Axapta 2.5 had only one form that used the BatchChangeStatus class and it was the Batch form. In Microsoft Dynamics AX 3.0, an improved approach was implemented. After the BatchChangeStatus class was processed, it called the doReselect method of the form. This method should apply extended functions when re-executing the query, for example, after reexecuting the query it should restore the record that was selected before. In Microsoft Dynamics AX 3.0, the new form for operating with a Batch has been added – the BatchUser form. The doReselect method has been implemented in the Batch form, but by mistake it was not in the BatchUser form. • Solution The doReselect method has been added to the BatchUser form where it was missing before. It does the same as it did in the Batch form - reexecutes the query and restores the record that was selected by the user before. The BatchChangeStatus is not used in any other forms in Microsoft Dynamics AX. |
\Forms\BatchUser | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #5195 | Not available | In document handling, if the user deleted the document that, in fact, was a link to a file on a computer in a network, the linked file was also deleted without any notification. | • Problem In document handling, if the user deleted the document that, in fact, was a link to a file on a computer in a network, the linked file was also deleted without any notification. The issue occurred because of a mistake in the design of the document handling functionality. • Solution For document types having the File location set to ‘Archive directory’ or ‘Original location’, two new options have been added:
|
\Data Dictionary\Tables\DocuRef \Forms\DocuType \Data Dictionary\Base Enums\DocuRemoveOption \Data Dictionary\Tables\DocuType | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #5246 | Not available | An unclear error message sometimes appeared if the Use Amount Table function was used while processing an OLAP Cube instance. | • Problem The "Error executing code: The field with ID ‘0’ does not exist in table ‘CustTransOpen’" run-time error could occur if the Use Amount Table function was used while processing an OLAP Cube instance. The issue occurred because there was no Currency code field on the CustTransOpen table. This field was required by the OLAP functionality to properly process currency amounts. • Solution The new error message has been created to properly inform the user of the cause of the error. |
\Data Dictionary\Table\OLAPCube \Classes\OLAPCreateAmount | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #6864 | Not available | Data import was performed very slowly for tables that use transaction ID system fields when the import file contained many transaction IDs. | • Problem Data import was performed very slowly for tables that use transaction ID system fields when the import file contained many transaction IDs. The issue occurred because the TmpTransactionIdMap table had no indexes. As a result, a full table scan had to be performed for this table to update each record using transaction ID system fields. • Solution A cluster index on the Id field of the TmpTransactionIdMap table has been created to make lookups using this field more effective. |
\Data
Dictionary\Tables\TmpTransactionIdMap \Classes\SysDataImport | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #7624 | Not available | The Microsoft Dynamics AX file deployment used for copying missing or outdated files from the server to the client sometimes did not function properly. | • Problem The Microsoft Dynamics AX file deployment used for copying missing or outdated files from the server to the client sometimes did not function properly. The issue occurred because the file deployment functionality used the path to a file that was relative to the client computer. In particular, in the \Classes\SysFileDeployment\copy method, there was a call to the function that should copy files from the server to the client, but the path to the server file was calculated incorrectly. Besides, in the \Classes\WinAPI\setFileTimeServer2Client method, an error occurred when there was an attempt to close the file that was open on the server side with the \Classes\WinAPI\CloseHandle method executed on the client side. • Solution The SysFileDeployment.sourcePath() method has been modified to return the path on the server machine. To do this, a new static method with the ‘server’ modifier (it forces this method to be executed on the server side) has been implemented. To correct closing files opened on the server side, a new method has been implemented. |
\Classes\SysFileDeployment \Classes\WinAPI | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #7630 | Not available | The state of the All level check box was sometimes updated incorrectly when switching between the tab pages of the Cube Definition Manager form. | • Problem The state of the All level check box was sometimes updated incorrectly when switching between the tab pages of the Cube Definition Manager form. The issue occurred because the check box was hidden at the moment the Levels tab became active. • Solution The code has been modified to update the state of the All level check box before activating the Levels tab. |
\Forms\OLAPCDM | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #7643 | Not available | Some tables in the CRM module had nonunique primary indexes set. | • Problem Some tables in the CRM module had nonunique primary indexes set. Also, the user could set the tables’ Primary index property to a non-unique index by typing in the index name. The issue occurred because indexes selected as the Primary index property values were not assured to be unique. • Solution The code has been modified so that primary indexes are set to unique indexes. For tables having no unique indexes, no primary index is defined. Also, the user cannot set the tables’ Primary index property to a non-unique index. |
\Data Dictionary\Tables\smmCampaignResponsibility \Data Dictionary\Tables\smmCampaignQuery \Data Dictionary\Tables\smmCampaignMediaType \Data Dictionary\Tables\smmReportQuotationReasonGroup | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #7981 | Not available | The security settings for the OLAP cubes set in the Cube Definition Manager form were ignored by the system. | • Problem The security settings for the OLAP cubes set in the Cube Definition Manager form were ignored by the system. The issue occurred because the code needed to take the security settings was not implemented. • Solution The code has been modified to take the security settings specified for the OLAP cubes into account. |
\Data Dictionary\Tables\OLAPCubeInstance \Data Dictionary\Tables\OLAPCube \Forms\OLAPCDM \Forms\OLAPCubeInstance \Forms\OLAPPivotTable | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #8205 | Not available | The correct table space was not displayed in the Storage setup form (SysSQLSetup in the AOT). | • Problem The correct table space was not displayed in the Storage setup form (SysSQLSetup in the AOT). For a new installation, the SYSTEM table space was displayed. The issue occurred because the default table space setting was not loaded from the database. • Solution The combo box that displays table spaces has been initialized to display the default table space for the database user. |
\Forms\SysSqlSetup | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #8341 | Not available | The table list did not display all tables if the user created a report for the ContactPerson table using the Report Wizard and did not use system names. | • Problem The table list did not display all tables if the user created a report for the ContactPerson table using the Report Wizard and did not use system names. The issue occurred because the information about the tables names and labels was stored in the Map object that had the name of a table or label of a table as a key. Therefore, when there were some tables with an identical label they were stored in one Map record. As a result, information on only one table was stored. • Solution The key of the internal Map object has been made unique. Also, when Microsoft Dynamics AX 3.0 fills in the tree view with the names of tables, it uses the MapIterator object and it sequentially iterates on the map. The iteration order is based on the Map key type, for example ‘Integer’, ‘String’, ‘Object’ and so on. In our case, the key was of the ‘String’ type, therefore, the order was alphabetical. Now the key of Map is based on the ‘Container’ type. This container is filled in with the table_name/table_value, table_id values. This pair is unique. Also, the order in which the MapIterator object goes through Map is the same as it was before the modifications. Therefore, the order is based on the complex key that consists of the table_name/table_label and table_id values. |
\Classes\SysReportWizard | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #8360 | Not available | When using the Database log reports, the report generation could fail if there were manipulations with the fields for tables being logged. | • Problem When using the Database log reports, the report generation could fail if there were manipulations with the fields for tables being logged. The issue occurred because there was no check operation in the SysDatabaseLog::getDataAsList method to verify if a field exists in a table being logged. This caused the whole report generation to fail. • Solution A simple check operation has been added to verify if a field exists in a table when generating a report. |
\Data Dictionary\Tables\SysDatabaseLog\getDataAsList | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #8742 | Not available | When selecting purchase orders or sales orders for update in the Quotation or Purchase order forms, ranges on tables linked to the Inventory dimensions table were ignored. | • Problem When selecting purchase orders or sales orders for update in the Accounts receivable > Periodic > Sales update > Quotation or Accounts receivable > Periodic > Purchase order update > Purchase order forms, ranges on tables linked to the Inventory dimensions table were ignored. This issue occurred because the Inventory dimensions table was disabled without checking if any of its child data sources were needed. • Solution The code has been modified to verify if any child data source of the InventDim data source has ranges before disabling it. Also, since the disableInventDimIfNotUsed method is exactly the same in the PurchFormLetter and SalesFormLetter classes, its logic has been moved to their parent class, and it was replaced with stubs calling the super method. |
\Classes\FormLetter \Classes\PurchFormLetter \Classes\SalesFormLetter | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #9043 | Not available | The comma sign was always used while generating quotation documents regardless of the locale settings. | • Problem The comma sign was always used while generating quotation documents regardless of the locale settings. The issue occurred because the DocuActiontrans::insertField function called num2str with the comma separator specified. • Solution Modifications have been made to call num2str with the ‘-1’ argument for the decimal separator to force the system use the default decimal separator. |
\Classes\DocuActionTrans\insertField | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #9537 | Not available | The pivot table filtering and sorting settings were not saved in the pivot view setup. | • Problem The pivot table filtering and sorting settings were not saved in the pivot view setup. The issue occurred because of the design of the pivot table view setup saving functionality. • Solution The pivot table filtering and sorting settings will now be saved in the PivotFieldsSetup container field of the OLAPViewSetupDimension table. |
\Classes\OLAPPivotFieldSetup \Classes\OLAPPivotFieldSetSetup \Classes\OLAPViewSetupSave \Classes\OLAPPivotTable \Data Dictionary\Tables\OLAPViewSetupDimension | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #9611 | Not available | If the report query contained a data source with the OrderMode property set to ‘Group by’, the user could not add or modify new parameter/criteria lines even if the query data source had the Allow add property set to ‘All fields’. | • Problem If the report query contained a data source with the OrderMode property set to ‘Group by’, the user could not add or modify new parameter/criteria lines even if the query data source had the Allow add property set to ‘All fields’. Also, the user was not able to change some parameters of the sorting order, such as Sorting direction, Subheading, Group totals. On the initialization stage, the SysQueryForm class put the data source ID in a temporary table. The criteria used was that the corresponding data source had the Allow add property set to ‘All fields’ and its Order mode property set to ‘Order by’. In later processing, Microsoft Dynamics AX 3.0 used the record in this table to check if ranges or sorting orders can be edited for the corresponding data source. If this temporary table did not contain record for the corresponding data source, the user could not edit the ranges and criteria. • Solution The condition that did not allow a data source to be put in the temporary table if it had the Order mode property not set to ‘Order by’ has been removed. Additional conditions have been implemented in the code that enables/disables editing of the sorting order fields. This condition restricts the editing of the sorting fields if the query contains a data source with the order mode set to ‘Group by’. A new public function has been implemented in the SysQueryForm class. It returns TRUE if the query contains data sources with the Group by order mode. |
\Forms\SysQueryForm \Classes\SysQueryForm | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #9760 | Not available | In document handling, when the user used a bookmark linked to an enum field, the enum value (0, 1, 2, 3) was displayed in the document rather than the actual text. | • Problem In document handling, when the user used a bookmark linked to an enum field, the enum value (0, 1, 2, 3) was displayed in the document rather than the actual text. The issue was caused by using the enum value (0, 1, 2 and so on) without converting it to text. • Solution The value of the enum fields will now be converted to its text representation. |
\Classes\DocuActionTrans | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #9911 | Not available | The document handling settings were not updated when the user switched to another company. | • Problem The document handling settings were not updated when the user switched to another company. The infolog.docu().useTablesEnabled parameter was only updated on startup and when this setting was modified in the DocuParameters form. Also, when a form from the noncurrent company was activated while the Document handling form was opened, the Docu.reSearch method was called before the change to the Company form occurred. Because of this, the document handling settings for an incorrect company were used. • Solution The Docu object settings are updated when a company is changed in the Application.setDefaultCompany method. Also, the Docu.reSearch method has been modified to determine the document handling settings correctly when a form being activated is not in the current company. |
\Classes\Application \Classes\Docu | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #9912 | Not available | The selection of OLAP cubes from all modules was shown when a menu item was set up to show only cubes from a certain module. | • Problem The selection of OLAP cubes from all modules was shown when a menu item was set up to show only cubes from a certain module. When searching for available cubes, the logic implemented in the \Classes\OLAPRecord2Instance\init method was used:
• Solution The checks for OLAP cube modules are enabled when looking for the available OLAP cubes. |
\Classes\OLAPRecord2Instance | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #10092 | Not available | In the Printing options dialog box in Microsoft Dynamics AX 3.0, the paper orientation and number of copies changed if these properties were modified in the system built-in Printer properties dialog box. | • Problem In the Printing options dialog box in Microsoft Dynamics AX 3.0, the paper orientation and number of copies changed if these properties were modified in the system built-in Printer properties dialog box. Printing options in Microsoft Dynamics AX 3.0 were modified in the \Forms\SysPrintForm\Methods\printerProperties method after the system Printer properties dialog box was displayed. Also, the parmPaperOrientation and parmPreferredOrientation methods of the SysPrintOptions class were used inconsistently in the SysPrintForm form resulting in an improper behavior of the Paper orientation selection control. • Solution The code has been modified so that the previous paper orientation and number of copies are restored after displaying the Printer properties dialog box, so that they remain valid. Additionally, both the parmPaperOrientation and parmPreferredOrientation parameters are now changed in the SysPrintForm form. |
\Forms\SysPrintForm \Classes\SysPrintOptions | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #10234 | Not available | In document handling, a new instance of Microsoft Word was always started even if the already running instance had no open documents. | • Problem In document handling, a new instance of Microsoft Word was always started even if the already running instance had no open documents. The issue occurred because the new operator was used every time the Microsoft Word instance was requested. • Solution The code has been modified to check for already running Word instances, and if so, to reuse them. |
\Classes\DocuActionCOM_Word | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #10305 | Not available | No labels were imported or created when importing Microsoft Dynamics AX export files (xpo) without the Show details check box selected. | • Problem No labels were imported or created when importing Microsoft Dynamics AX export files (xpo) without the Show details check box selected. The issue occurred because the internal variable used for importing labels was filled in from the tree control. However, the tree control was initialized only when the user selected the Show details check box. • Solution The import labels functionality has been modified not to depend on the Show details check box while importing or creating labels during the import of Microsoft Dynamics AX export files. |
\Classes\SysImportElements | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #10534 | KB907814 | Captions in PDF files generated using the special bar code fonts looked corrupted. | • Problem Captions in PDF files generated using the special bar code fonts looked corrupted. The issue occurred because the isTrueType method returned FALSE. As a result, the bar code font was interpreted as a non-TrueType, though it was a TrueType font. • Solution The code has been modified to make isTrueType return TRUE. |
\Classes\PTC_SysPDFIDAutomation\isTrueType | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #10867 | Not available | When posting sales orders with the check boxes like Print shipping labels selected in the Posting forms, the next time when the form was opened, the selections were not saved. | • Problem When posting sales orders with the check boxes like Print shipping labels selected in the Posting forms, the next time when the form was opened, the selections were not saved. The issue occurred because the setup of the SalesEditLines form look was performed too late. Therefore, the saved changes were not properly recovered and were not reflected in the form being displayed. • Solution The form setup code has been moved to the place before the call to super() in the form’s run() method. |
\Forms\SalesEditLines\run() | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #10927 | Not available | When the user imported records into an existing company where some of the imported records already existed, only some of the records could be actually imported. | • Problem When the user imported records into an existing company where some of the imported records already existed, only some of the records could be actually imported. As a result, not all records were imported, including records that had no duplicates in the existing company During the import operation, ttsCommit was performed every thousand records or on every new imported table. Therefore, when on any import step the user got an error, all insert/update operations processed since the last commit operation were rolled back. This explains why records which did not have duplicates were not inserted, because they were a part of the transaction that was rolled back. There was no possibility of setting up the import operation to leave the existing records. Therefore, if the user did not select the Update records option, all of the records were inserted, leading to error messages. Also, at the end of the import operation, the results were shown in the Infolog message. However, Microsoft Dynamics AX 3.0 showed the time of importing and numbers of some records, though this number showed not the number of actually imported records, but the number of all records in the import file. During the import operation, some records were not imported because of an error or if the user stopped the import. Thus, the actual number of imported records was not the same as the number shown to the user. • Solution A new parameter that indicates whether duplicate records should be skipped or an error message should be displayed has been added to the import functionality. For handling this parameter, a new field has been added in the Import options dialog box. If the user sets this parameter, then a check is performed during the import to make sure that records do not already exist. If they exist in an imported table, they are skipped. If this parameter is not set, then the import functionality works as previously – no check on existing record is done. Also, new counter variables have been added to the import functionality for displaying the actual number of imported records. |
\Classes\SysDataImport \Application Documentation\Classes\SysDataImport | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #10928 | Not available | A compiler error occurred if the string starting with "(" was used in Microsoft Dynamics AX 3.0 query conditions. | • Problem A compiler error occurred if the string starting with "(" was used in Microsoft Dynamics AX 3.0 query conditions. The code in kernel has a special check for the opening clause and treats the remaining string as an expression. However, Microsoft Dynamics AX 3.0 also appends the "\" symbol to the special characters like spaces. This combination could not compile, because the expression does not allow using the "\" symbol. • Solution A check for the opening clause is performed in the SysQuery::value method and if the second character after pre-processing is slash, the value is treated as a string and not as an expression. Therefore, the string is wrapped in quotes. |
\Classes\SysQuery\value | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #11439 | Not available | When the user ran Microsoft Dynamics AX 3.0 in a 3-tier configuration, updates to the lines sometimes updated the other lines in the same data source. | • Problem When the user ran Microsoft Dynamics AX 3.0 in a 3-tier configuration, updates to the lines sometimes updated the other lines in the same data source. This happened to forms with linked data sources. The issue occurred because the linked cursors were not updated when the Display methods were called. The cqlcursor::addCursorData method packs the cursor information to send to the server when calling UpdateDirty. This method packed the joined cursors only for the Next/Select calls, but not for the Display methods. This caused the loss of synchronization between the joined cursors and the master cursor. • Solution The cache for the InventDim data source will now be refreshed when the parent Purchline/SalesLine data source is changed. |
\Forms\SalesTable\Data
Sources\Purchline\write \Forms\PurchTable\Data Sources\Purchline\write | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #11639 | Not available | Microsoft Dynamics AX 3.0 might stop responding if the user entered spaces in the Address field. | • Problem Microsoft Dynamics AX 3.0 might stop responding if the user entered spaces in the Address field. In the AddressMap.setAddress method, there was a logic that was supposed to cut away the spaces and new line characters, which might occur at the end of the Address field. This logic entered an endless loop if the field contained only spaces and/or new line characters. • Solution The logic for cutting out the new lines and spaces has been rewritten. |
\Data Dictionary\Maps\AddressMap\Methods\setAddress | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #11731 | Not available | If some data was specified for the report while running it for the first time and the Reset functionality was used when running the report next time, the old data was taken into account. | • Problem If some data was specified for the report (for example, Inventory management > Reports > Transactions > Inventory transactions) while running it for the first time and the Reset functionality was used when running the report next time, the old data was taken into account. The ReportRun class contains two variables - Query and QueryRun, which are of the ‘query’ and ‘queryRun’ types respectively. The ‘queryRun’ object also contains a reference to the query that it will use. Initially, reportRun.query() was equal to reportRun.queryRun().query(). However, after creating a new query with the Reset functionality, only reportRun.query(newQuery) was called. Therefore, reportRun.query() was not equal to reportRun.queryRun().query(). However, when the report was executed, only reportRun.queryRun().query() was taken into account. • Solution When a new empty query is created with the Reset functionality, the query used in the report (queryRun.query()) will also be updated. |
\Classes\RunBaseReport | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #11748 | Not available | Record id references were imported incorrectly and the "SQL command not properly ended" database error ORA-00933 appeared when data with record id references was imported using the Oracle database backend. | • Problem Record id references were imported incorrectly and the "SQL command not properly ended" database error ORA-00933 appeared when data with record id references was imported using the Oracle database backend. The issue occurred because the FROM clause was used in the UPDATE statement. It is allowed in the SQL Server 2000 dialect of SQL, but forbidden in the Oracle 9 dialect. • Solution The FROM clause has been removed from the generated statements to make them valid in both SQL dialects. |
\Classes\SysDataImport | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #12209 | Not available | For some regional settings, date ranges worked incorrectly in the Packing material weight and Packing material weight – purchase reports | • Problem For some regional settings, date ranges worked incorrectly in the Packing material weight and Packing material weight – purchase reports (Inventory management > Reports > Packing material). In the setRangeForInvoiceDate method of the InventReport_PackagingMaterialWeights class (and similarly in the InventReport_PackagingMaterialWeightsPurch class), a query range string was generated the way that the ‘dd.mm.yyyy’ format was always used for dates. If the date format set up by user was different (for example, ‘mm/dd/yy’), this range string was parsed incorrectly. • Solution The date format defined by the regional settings is used. |
\Classes\InventReport_PackagingMaterialWeights \Classes\InventReport_PackMaterialWeightsPurch | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #12433 | Not available | When using the DOWN ARROW key in the SysDataSearchManager form to create a new record, an error message was displayed. Also, the previous record became damaged. | • Problem When using the DOWN ARROW key in the SysDataSearchManager form to create a new record, an error message was displayed. Also, the previous record became damaged. The issue occurred because the leave() override was called twice when the user pressed the DOWN ARROW key. • Solution Creating new records using the DOWN ARROW key has been disabled by setting the InsertAtEnd property of the SysDataSearch data source to ‘NO’. |
\Forms\SysDataSearchManager\DataSources\SysDataSearch | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #12777 | KB910845 | If the user tried to use the Filter option in the shortcut menu opened for the TransDate column in the Account reconciliation form, the Remove filter option was disabled. | • Problem If the user tried to use the Filter option in the shortcut menu opened for the TransDate column in the Account reconciliation form, the Remove filter option was disabled. The Equal method was called to check the current query and the query that was used to form the initial list. If the queries were equal, the button was not enabled. The issue occurred because the queries were detected to be equal even though the existing TransDate range in the query was changed. This happened because the TransDate range was created in the Init method of the data source and was never used. • Solution The query initialization has been corrected to not create the TransDate range. |
\Forms\BankReconciliation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #13167 | KB910278 | If Microsoft SQL Server DBMS was used as a backend database in
Microsoft Dynamics AX 3.0 and the database was set to be initialized
for Unicode, not all database fields were initialized correctly. Text
fields were initialized as ANSI text, not as Unicode text. Also, if a database was initialized for Unicode, then a text with national characters was not saved correctly in the fields of ‘Memo’ type. |
• Problem If Microsoft SQL Server DBMS was used as a backend database in Microsoft Dynamics AX 3.0 and the database was set to be initialized for Unicode, not all database fields were initialized correctly. Text fields were initialized as ANSI text, not as Unicode text. The issue occurred because of an error in the function of initialization of the list of data types to be used with a database. Also, if a database was initialized for Unicode, then a text with national characters was not saved correctly in the fields of ‘Memo’ type. The issue occurred because such fields were not handled correctly in the ODBC support module of Microsoft Dynamics AX 3.0 kernel. • Solution To have all fields correctly initialized for Unicode, the ‘NTEXT’ data type is used instead of ‘TEXT’. The code to store ‘Memo’ fields in Unicode has been added to the Microsoft Dynamics AX 3.0 ODBC support. |
\Classes\SqlDatabaseInit SQL-ODBC.CPP SQL-STMT.CPP | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #13299 | Not available | An incorrect address was used when one of several addresses with the same postal code was selected in the Address form. | • Problem An incorrect address was used when one of several addresses with the same postal code was selected in the Address form. The ZipCode table record was selected using only the ZipCodeId field in the \Classes\AxAddress\zipCodeRecord method or using the ZipCodeId and City fields in the \Data Dictionary\Maps\AddressMap method. Additionally, address fields were only updated for records already saved to the database in the \Forms\ZipCodeLookup\Methods\closeSelect method, because the AddressMap::initFromZipCode method was only called for such records. • Solution The ZipCode table record is selected using all the AddressMap map fields in the \Classes\AxAddress\zipCodeRecord method. In the \Data Dictionary\Maps\AddressMap method, an attempt to select the ZipCode record is done using all available fields first. The ZipCode::findBestMatch method is updated so that it can be used to search for exact matches of the ZipCode records only - that is, only records that are uniquely identified by input parameters are returned. This behavior is triggered by setting the allowAmbiguousZipCodeMatch parameter of this method to FALSE (if it is kept at default TRUE, which stands for the original behavior, the old code that uses this method will not be broken). Address fields are updated for records not saved in the database in the \Forms\ZipCodeLookup\Methods\closeSelect method. |
\Data Dictionary\Tables\ZipCode \Data Dictionary\Maps\AddressMap \Classes\AxAddress \Forms\ZipCodeLookup | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #13406 | Not available | Incorrect query range values appeared for the enum fields if the lookup was used to select the enum values that contained the following special characters: ‘,’, ‘..’, ‘<’, ‘>’, ‘=’, ‘(’, ‘)’, and ‘!’. | • Problem Incorrect query range values appeared for the enum fields if the lookup was used to select the enum values that contained the following special characters: ‘,’, ‘..’, ‘<’, ‘>’, ‘=’, ‘(’, ‘)’, and ‘!’. The issue occurred because, while using the lookup for the enum fields in the Query editor form, enum values that contained special characters were put into the range string as they were, without any changes. As a result, special characters that were present within the element names were parsed as logical operator symbols and incorrect database query was constructed. • Solution Necessary modifications have been made to quote the enum field values that contain special characters in the query range strings. |
\Forms\SysLookup | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #13749 | KB909566 | Barcode EAN13 was not printed when the length of the barcode string was 13. | • Problem Barcode EAN13 was not printed when the length of the barcode string was 13. The issue occurred because the barcode BC_EAN13 DLL function contained a mistake. • Solution The barcode BC_EAN13 DLL function accepts strings with the length of 12 only. It returns a string with 13 characters. The last one is the checksum character. To solve the problem, the supplied string is checked if it is 13 characters in length and only12 is used as an argument for the BC_EAN13 function. |
\Classes\BarcodeEAN_UPC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #14271 | KB914365 | If the user renamed businessAccount in the CRM module,
this affected documents of all legal companies implemented in Microsoft
Dynamics AX 3.0. If the Documents form was opened from the Business relations form and, in the Business relations form, the user changed the active record, a new document was created for a business relation that was active when the Documents form was opened, but not for currently selected one. |
• Problem If the user renamed businessAccount (BusRelAccount) in the CRM module, this affected documents of all legal companies implemented in Microsoft Dynamics AX 3.0. The DocuRef table had the BusRelAccount field that was based on the smmBusRelAccount extended data type. This extended data type had a relation to the smmBusRelTable table. When the user performed the rename primary key operation on the smmBusRelTable table, the system changed the corresponding field in the DocuRef table. Since the DocuRef table does not store data on a per company basis, all records that had the same BusRelAccount field value remained touched. If the Documents form (smmDocuments) was opened from the Business relations form (smmBusRelTable) and, in the Business relations form, the user changed the active record, a new document was created for the business relation that was active when the Documents form was opened, but not for the currently selected one. While opening the smmDocuments form, record Id of the caller’s active record was stored. It was done in the Init() method. However, the system dynamically linked these forms and when a record in the caller form was changed the smmDocuments form was updated to reflect the information about the currently selected record. However, the stored record id was not updated and became incorrect. • Solution The relation on the BusRelAccount field in the Document references table to the Business relation table based on the extended data type has been dropped. A new relation to the Business relation table has been added to the Document references table. Functionality that creates a new document in the Documents form has been corrected to work with the currently selected business relation. |
\Data Dictionary\Tables\DocuRef \Data Dictionary\Tables\smmBusRelTable\ \Data Dictionary\Extended Data Types\smmBusRelAccountBase \Data Dictionary\Extended Data Types\smmBusRelAccount \Forms\smmDocuments | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #15241 | Not available | The "Cannot select a record in Batch transactions. Priority: 0; Deadlock where one or more users have simultaneously locked the whole table or part of it" error message appeared from time to time on a client running a batch queue. | • Problem The "Cannot select a record in Batch transactions. Priority: 0; Deadlock where one or more users have simultaneously locked the whole table or part of it" error message appeared from time to time on a client running a batch queue. The issue was caused by the code that in case of intense usage of the batch functionality (many batch clients executed) could lead to a deadlock error. The \Classes\BatchRun\cleanUpExecuting method put a lock on many records of the Batch table. • Solution The \Classes\BatchRun\cleanUpExecuting method has been improved to lock only the currently processed record. Also, if the AOS is intensely loaded, a call to the isSessionActive method can be time consuming. Therefore, information for the Batch record can be changed – for example, a batch job was finished. To prevent this situation, an additional check has been added. |
\Classes\BatchRun | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #15488 | KB917260 | The user could not set up some reports executed on the server to use server printers. | • Problem The user could not set up some reports executed on the server to use server printers. When the SalesFormLetter* and PurchFormLetter* reports were set up, the callPrinterSettings* static methods of the SalesFormLetter and PurchFormLetter classes were used to show the Printing preferences form. These methods were set up to run on the client and, as a result, printing settings objects were created on the client and used only client printers. • Solution The callPrinterSettings* methods have been modified to run on the server to create printing settings objects on the server and allow selecting both client and server printers. |
\Classes\SalesFormLetter \Classes\PurchFormLetter | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #15941 | Not available | When the user created a Word document from the sales order and this document included the contact person’s name, the document actually included all of the customer’s contact persons instead of the sales order contact person. | • Problem When the user created a Word document from the sales order and this document included the contact person’s name, the document actually included all of the customer’s contact persons instead of the sales order contact person. To select the contact person’s name from the ContactPerson table, a dynamic query was used. The \Data Dictionary\Tables\DocuField\Methods\relationQuery method was used for creating that query. This method contains an instance of the DictRelation class. The DictRelation\loadTableRelation method was used to determine the relation between the SalesTable and ContactPerson tables. Since tableId of ContactPerson was passed to the loadTableRelation method and tableId of SalesTable was passed to the constructor of the DictRelation class, the table relation was determined in the following order:
• Solution The code has been modified so that the Word document created from a sales order includes the contact person name specified in the sales order header. |
\Data Dictionary\Tables\DocuField | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #16207 | KB918489 | The "Mail error: The type of the recipient was not MAPI_TO, MAPI_CC or MAPI_BCC. No message was sent" error occurred on an attempt to send an e-mail message from the Customers and Vendors forms if Outlook Express was set as the default e-mail client. | • Problem The "Mail error: The type of the recipient was not MAPI_TO, MAPI_CC or MAPI_BCC. No message was sent" error occurred on an attempt to send an e-mail message from the Customers and Vendors forms if Outlook Express was set as the default e-mail client. The issue occurred because the MAPIResolveName base MAPI function always returned type of recipient equal to ‘0’ (MAPI_ORIG) if the user had Outlook Express set as the default mail client and this value was not acceptable for the MAPISendMail MAPI function. • Solution The additional initialization has been implemented in the SysInetMail class, because some default values returned by the kernel could be incorrect depending on the MAPI client installed on the user's computer. |
\Classes\SysINetMail | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #17128 | KB920292 | Performance of the export functionality for the document nodes was very poor. | • Problem Performance of the export functionality for the document nodes was very poor. The poor performance was caused by an algorithm that initially gathered into the memory buffer all of the RecIds in the DocuRef table that matched the criteria. Then the algorithm extracted RecIds from the buffer one-by-one and executed the SELECT statement with it to get all the necessary data for the export. This caused the SELECT statement to be called for each record in the DocuRef table. • Solution The algorithm has been redesigned to export DocuRef records using just one select statement. |
\Classes\SysDataExport | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #17231 | Not available | The SysDataBaseLog form caused a critical stop error when a logged table contained field of the ‘Container’ type. | • Problem The SysDataBaseLog form caused a critical stop error when a logged table contained field of the ‘Container’ type. The issue occurred because the strFmt method caused an error to occur when one of its parameters had a ‘Container’ data type. • Solution The code has been modified so that the length of the ‘Container’-based field is used as its string representation in the SysDataBaseLog form. |
\Data Dictionary\Tables\SysDataBaseLog | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #17535 | Not available | The sorting order was incorrect when using the batch forms. | • Problem The sorting order was incorrect when using batch forms. Batch jobs on these forms were ordered by the Created Date/Time instead of the Start Date/Time, which is more appropriate. The issue occurred because the index of the Batch table had Created Date/Time. • Solution A new index has been introduced with StartDate/Time. This index has been assigned for the datasources of the Batch and BatchUser forms. |
\Forms\Batch \Forms\BatchUser \Data Dictionary\Tables\Batch \Classes\BatchRun | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #17696 | KB921289 | Controls were misplaced in the Report options dialog box after modifying the report query if there were no ranges for some of the report data sources. | • Problem Controls were misplaced in the Report options dialog box after modifying the report query if there were no ranges for some of the report data sources. The issue occurred because some blank space was allocated for the empty data sources when the corresponding control groups became enabled after modifying the report query. • Solution The code has been modified so that unused control groups will not be enabled after the user modifies the report query to make sure that the Report options dialog box is formatted properly. |
\Classes\RunBaseDialogModify | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #18814 | KB924091 | It was not possible to print US checks at the bottom of the paper – there was a hard coded minimal width of the bottom margin. | • Problem It was not possible to print US checks at the bottom of the paper – there was a hard coded minimal width of the bottom margin. In particular, an attempt to print a US check (which is 3.5 inches high) on a Letter page (11 inches high) starting from vertical position of 7.5 inches failed on printer with no unprintable area at the bottom of the page. The issue occurred because the bottom margin minimal width was hard coded. • Solution The hard-coded bottom margins have been removed from the check layout testing logic. |
\Classes\BankPrintTestCheque \Classes\VendCheque \Reports\Cheque_US |