17.08.2005, 09:18 | #1 |
Участник
|
Что за поле LedgerBalancesTrans.LedgerBalancesVariant?
Собственно, сабж. Даже лэйбла к нему нет (и к его расширенному типу).
|
|
17.08.2005, 09:39 | #2 |
Moderator
|
Класс LedgerVoucherBalancesList
переменная variant потом может инициализироватьи обновлять LedgerBalancesVariant PHP код:
|
|
17.08.2005, 09:41 | #3 |
Участник
|
А для чего это поле нужно в таблице?
|
|
17.08.2005, 09:51 | #4 |
Moderator
|
ИМХО: судя по результатам поиска в АОТ-е это поле используется при поиске (как параметр для поиска) и сортировке.
|
|
17.08.2005, 10:46 | #5 |
Moderator
|
Это поле добавлено в версии 3.0 для уменьшения взаимных блокировок.
Грубо говоря - идея следующая: В старой Axapta (2.5/2.1) обороты по счетам и аналитикам накапливались в таблицах ledgerBalances и ledgerBalancesDim в разрезе счетов и периодов и в разрезе счетов, периодов и аналитик соответственно. Классы разноски в ledgerTrans после записи в саму ledgerTrans обновляли обороты в этих таблицах. Соответственно - если я начинал разносить журнал из 5000 строк, система обновляла одну из строк в ledgerBalances (скажем - по счету 60.01) и эта строка блокировалась до конца транзакции. При этом все остальные транзакции, которые пытались выполнить проводку на счет 60.01, ожидали ее окончания. Ну а поскольку разноска журнала из 5000 строк может занимать эдак часик, а то и два, все это приводило к высокому уровню блокировок, и большому количеству перекуров среди пользователей. В версии 3.0 эти таблицы заменили на таблицы ledgerBalancesTrans и ledgerBalancesDimTrans. При этом - обороты по счету могут записываться в любую из 20 строк которые этому счету соответствуют. То есть - при обновлении ledgerTrans система более или менее случаным (в зависимости от номера сессии) образом выбирает одну из этих строк и пишет туда сумму оборотов. Благодаря этому - вероятность взаимных блокировок уменьшается в 20 раз. В то же время - если классам LedgerBalanceDim* или подобным необходимо посчитать обороты за период, то в общем-то, не возникает большой разницы между чтением одной строки из таблицы и чтением 20 строк из той же таблицы (Серверное железо-то теперь очень даже мощное). Так что тут проблем с производительностью не возникает. |
|
|
За это сообщение автора поблагодарили: mazzy (5), konopello (1), alex55 (1). |
13.06.2007, 16:47 | #6 |
Участник
|
Возвращаюсь к вопросу о LedgerBalancesDimTrans.
А объясните, как может быть, что в LT только одна проводка на 800К, а в LedgerBalancesDimTrans две на ту же сумму и отличаются они только этим полем LedgerBalancesVariant? Из-за этого в отчёт попадают задвоенные обороты и выходит, что этой агрегированной таблицей пользоваться не стоит.
__________________
Умные тоже наступают на грабли, но только для того, чтобы поднять их с земли не нагибаясь. |
|
14.06.2007, 10:09 | #7 |
Участник
|
Цитата:
Сообщение от gaenar
Возвращаюсь к вопросу о LedgerBalancesDimTrans.
А объясните, как может быть, что в LT только одна проводка на 800К, а в LedgerBalancesDimTrans две на ту же сумму и отличаются они только этим полем LedgerBalancesVariant? Из-за этого в отчёт попадают задвоенные обороты и выходит, что этой агрегированной таблицей пользоваться не стоит. 2. Несоответствие итогов и проводок может создать только программист или администратор 2.1. Программист может вместо методов Insert, Update, Delete вызвать методы doInsert, doUpdate, doDelete. При вызове do-методов ядро не выполняет предопределенные процедуры. Следовательно при вызове do-методов на таблице проводок не изменятся итоги 2.2. администратор может выполнить какие-либо операции над таблицей проводок средствами СУБД. Если программист и администратор вручную вмешиваются в базу, то они должны вручную обеспечить целостность базы. В данном случае пересчитать итоги. Бухгалтерские итоги пересчитываются Главное меню \ Главная книга \ Периодические операции \ Пересчет данных периодов |
|
14.06.2007, 11:54 | #8 |
Участник
|
Да, после пересчёта всё хорошо. Спасибо.
Попрошу добавить в пакет на ночь. Забывают пересчитывать вручную после смены аналитики средствами программиста. By the way... не могу понять, зачем в русской локализации код, отвечающий за добавление LedgerBalancesDimTrans и LedgerBalancesTrans вынесен из LedgerVoucherTransObject.postGroup() и занесён в "пост-проверку" в LedgerVoucher.post() ( в тело цикла for (more = ledgerTransList.first(ledgerTrans) ). Причём в зависимости от параметра Correspondense_RU. Видимо, из-за того, что метод splitTrans не возвращает созданный корреспондирующий LedgerTrans, и положить его в LedgerBalancesXXX сразу нет возможности.
__________________
Умные тоже наступают на грабли, но только для того, чтобы поднять их с земли не нагибаясь. Последний раз редактировалось gaenar; 14.06.2007 в 13:45. |
|
Теги |
ax3.0 |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|