FetchMode property sometimes was a magic solution for report development in Axapta 3.0. Since then I wanted to run several tests and describe the feature. Problem description Analyse how a query is translated into SQL Server query based on FetchMode property. Solution Based on the description in msdn FetchMode property is available on an embedded datasource and determines a relation between parent and child datasources. FetchMode values are 1:1 and 1:n , but there is no description of them. The property name and values can lead to an assumption: 1:1 - data for parent and child datasources is fetched simultaneously 1:n - data for parent and child datasources is fetched separately. Running ahead I must say that the assumption is not precisely correct, but let's analyse it. You can also jump to the conclusion section. Case 1. FetchMode set to 1:1 All embedded datasources of CustCollectionLetterOverview query have FetchMode set to 1:1 : The query is translated into SQL Server query (hereafter some parts are omitted for simplicity): SELECT ... FROM CUSTCOLLECTIONLETTERJOUR T1 CROSS JOIN CUSTCOLLECTIONLETTERTRANS T2 CROSS JOIN CUSTTABLE T3 CROSS JOIN CUSTTRANS T4 CROSS JOIN DIRPARTYTABLE T5 ... Case 2. FetchMode set to 1:n All embedded datasources of CustInterest query have FetchMode set to 1:n : The query is translated into 3 SQL Server queries. SQL Server query 1: SELECT ... FROM CUSTTABLE T1 ... SQL Server query 2: SELECT ... FROM CUSTTRANSOPEN T1 WHERE ... ACCOUNTNUM=@P3 ... SQL Server query 3: SELECT ... FROM CUSTSETTLEMENT T1 WHERE ... ACCOUNTNUM=@P3 ... So far the assumption is correct. Note : There is logical error in the query - actual join mode on CustTransOpen and CustSettlement datasources is OuterJoin due to FetchMode specifics. Case 3. FetchMode set to 1:n and 1:1 Embedded datasources of AssetAcquisition query have different FetchMode values: The query is translated into SQL Server query: SELECT ... FROM ASSETTABLE T1 CROSS JOIN ASSETBOOKMERGE T2 LEFT OUTER JOIN VENDTABLE T3 ... LEFT OUTER JOIN DIRPARTYTABLE T4 ... Based on the assumption there should be 2 SQL Server queries - one for AssetTable and one for AssetBookMerge with child datasources. Case 4. FetchMode set to 1:n All embedded datasources of CustInterestCreate query also have FetchMode set to 1:n : The query is translated into 3 SQL Server queries: SQL Server query 1: SELECT ... FROM CUSTTABLE T1 CROSS JOIN CUSTTRANS T2 ... SQL Server query 2: SELECT ... FROM CUSTSETTLEMENT T1 WHERE ... (((TRANSCOMPANY=@P3) AND (TRANSRECID=@P4)) AND (ACCOUNTNUM=@P5) ... SQL Server query 3: SELECT ... FROM CUSTTRANSOPEN T1 WHERE ... (ACCOUNTNUM=@P3) AND (REFRECID=@P4) ... So the query is split into several SQL Server queries provided there are multiple embedded datasources with FetchMode set to 1:n on the same level. Note : the same logical error - actual join mode on CustSettlement and CustTransOpen datasources is OuterJoin . Case 5. FetchMode set to 1:n and 1:1 I created CustGroupInfo query with 2 embedded datasources on the same level, but set different FetchMode : The query is translated into 2 SQL Server queries: SQL Server query 1: SELECT ... FROM CUSTGROUP T1 LEFT OUTER JOIN PAYMTERM T2 ... SQL Server query 2: SELECT ... FROM CUSTTABLE T1 WHERE ... CUSTGROUP=@P3 ... Conclusion Dynamics AX query is split into multiple SQL Server queries provided there are multiple embedded datasources on the same level and at least one of them has FetchMode set to 1:n . Otherwise AX query is translated into one SQL Server query. Combination of JoinMode set to InnerJoin and FetchMode set to 1:n can lead to logical error (see Case 2 and Case 4 ).
↧