13.08.2007, 22:29
|
#1
|
Участник
Регистрация: 28.11.2005
Адрес: Москва
|
Косячок в классе InventAdj_Cancel (fetchMode)
Наткнулся сегодня на «интересный» способ указывать fetchMode в Query. Так, в методе InventAdj_Cancel.updateMultipleInvent() есть такие интересные строчки (AX 3.0 SP5 FP1)X++: inventSettlementDataSource = inventClosingDataSource.addDataSource(
tableNum(InventSettlement));
inventSettlementDataSource.fetchMode(JoinMode::INNERJOIN); Ну, казалось бы, ерунда, JoinMode::InnerJoin = 1 == QueryFetchMode::One2One, но далее в том же методе код еще интереснееX++: inventTransDataSource = inventSettlementDataSource.addDataSource(
TableNum(InventTrans));
inventTransDataSource.fetchMode(JoinMode::ExistsJoin); Я подозреваю, что Axapta при обработке свойства fetchMode делает проверку типаX++: if(fetchMode) { /* выборка 1:1 */ } т.е. ей, возможно, плевать, что значению 2 никакой QueryFetchMode не соответствует, однако, использование «левых» констант в стандартном коде как-то смущает Решил на всякий случай проверить Inventory Closing Rollup 2 для AX 3.0 и код в AX 4.0 SP1. В первом случае указанный метод класса InventAdj_Cancel модификации не подвергся, а вот в 4-ке совсем интересно: вместо JoinMode::INNERJOIN там красуется JoinMode::InnerJoin, т.е., видимо, код «подчищали» (хотя бы в плане регистра идентификаторов и ключевых слов - всякие «TableNum» канули в Лету), но значения констант оставили прежними: там все так же красуется fetchMode(JoinMode::ExistsJoin)
Использование JoinMode::InnerJoin в AX 3.0 SP5 FP1 для установки fetchMode встречается еще в методах RAssetCreateTaxAccount.new() и Tax.queryTaxCodeIntersection(), JoinMode::ExistsJoin для этого вроде, к счастью, нигде больше не используется.
|
|
За это сообщение автора поблагодарили: Logger (2), vladz (1). |