Отправьте баги в Майкрософт

[glibs]

АОТ\Data Dictionary\Base Enums\OriginalDocument

Пункт 7, "Purchase".

Метка "@SYS23989" — "Requisition", "Заявка" некорректна, т.к. речь идет о заказе на покупку.

[glibs]

АОТ\Data Dictionary\Tables\CustInvoiceJour\Methods.origInvoiceId_PL()

Ощутимо подтормаживает на непустой но и весьма слабо заполненной базе.

Метод вызывается при открытии списка накладных клиентов (РК\Запросы\Журналы\Накладные).

Самому вникать в суть пока лень, но может есть способ оптимизировать производительность формы.

[gl00mie]

Цитата:

Сообщение от glibs

АОТ\Data Dictionary\Tables\CustInvoiceJour\Methods.origInvoiceId_PL()
Ощутимо подтормаживает на непустой но и весьма слабо заполненной базе.
Самому вникать в суть пока лень, но может есть способ оптимизировать производительность формы.

Как вариант, на CustInvoiceTrans выставить CreateRecIdIndex == Yes - в этом случае план запроса получается очень "дешевым":

[glibs]

В 4.0 сп2 у меня, вроде, стоит создание индекса по RecId. Может не туда смотрю, правда.

Запрос у меня отрабатывает 200-300-400-500-600 мс. Но для грида на форме получается тяжеловато.

[gl00mie]

Цитата:

Сообщение от glibs

Запрос у меня отрабатывает 200-300-400-500-600 мс.

Вроде слишком долго получается. Строки накладной должны выбираться по InvoiceIdx, который обладает достаточно хорошей селективностью, далее идет поиск строки "исходной" накладной по RecId, что при наличии соотв. индекса тоже должно занимать мало времени. Если только в накладных не тысячи строк и не получается какой-то кривой план запроса, запрос должен отрабатывать весьма шустро. В общем, нужно план запроса увидеть, иначе сложно что-то сказать.

[glibs]

Цитата:

Сообщение от gl00mie

...
Если только в накладных не тысячи строк
...

Бывает. Вообще да, накладные обычно большие. От полусотни строк.

[gl00mie]

Цитата:

Сообщение от glibs

Бывает. Вообще да, накладные обычно большие. От полусотни строк.

По-моему, в приведенном плане запроса слишком много вложенных циклов и сортировок. Я бы вообще переписал соотв. методы, избавившись от exist join и наложив условие на RefReturnInvoiceTrans_W, чтобы сузить выборку:

select firstonly forceplaceholders RecId
    from    invoiceTrans
    where   invoiceTrans.InvoiceId                  == this.InvoiceId
        &&  invoiceTrans.InvoiceDate                == this.InvoiceDate
        &&  invoiceTrans.SalesId                    == this.SalesId
        &&  invoiceTrans.NumberSequenceGroup        == this.NumberSequenceGroup
        &&  invoiceTrans.RefReturnInvoiceTrans_W
    join    InvoiceId, InvoiceDate
    from    origTrans
    where   invoiceTrans.RefReturnInvoiceTrans_W    == origTrans.RecId;

[Ivanhoe]

DAX 4.0 SP2: Ошибка при настройке RLS по таблицам без DataAreaId (SaveDataPerCompany=No):
Ошибка при определении запроса в RLS

[glibs]

В таблице RContractTypes security key стоит LedgerSetup, хотя должен быть LedgerTables.

[tourist]

server static InventUpd_Estimated newProdTable(
    ProdTable       _prodTable,
    Common          _childBuffer,
    ProdTableType   _prodTableType
    )
{
    if (_childBuffer.tableId)
    {
        if (_childBuffer.tableId == tableNum(ProdJournalProd))
             return new InventUpd_Estimated(new InventMov_Prod_JournalProd(_prodTable,_childBuffer,_prodTableType));

        return new InventUpd_Estimated(InventMovement::construct(_prodTable,false,_childBuffer));
    }return new InventUpd_Estimated(new InventMov_Prod(_prodTable,_prodTableType));
}

Здесь и в подобных местах условие

if (_childBuffer.tableId)

будет выполняться всегда, так как даже если buffer = NULL, то его tableId равен common.tableId , т.е 65535.

[Zabr]

Тема запроса с участием таблички markuptrans поднималась уже здесь оптимизируем запросы., но там речь шла об оптимизации.
Хочу добавить, что в этом коде есть еще и ошибка (с моей точки зрения). Если конфигурационный ключ markup (накладные расходы) не включен, то таблица не используется, джойнить ее бесполезно, и в этом случае надо было бы поставить условие на наличие ключа и вообще отключать запрос. Например, у нас такая проверка привела к кардинальному ускорению сопоставлений (скажем, разноска журналов банковской выписки с автоматическим сопоставлением ускорилась как минимум в 100 раз).

[glibs]

Есть финансовые отчеты. Которые были сделаны в 4.0.

Хотфикс KB948654 правит багу, когда некорректно рассчитывается строка с типом "Расчет".

Но осталась следующая бага. Если создать группу, в нее включить несколько таких строчек типа "Расчет", а для группы попросить вывести заголовок и подитог, то подитог считается неверно (закономерность некорректности не выявлена, иногда суммируются не все строчки, иногда вообще ни одна).

1. Создать фокус со счетом ГК.
2. Создать финотчет с двумя колонками: с типом "Название" (назвать "Name") и с типом "Текущий" (назвать "Value").
3. Указать там созданный фокус и строки (создать новые).
4. Строки настроить следующим образом. В корне группа (назвать "Group"), для которой отображаются компоненты, заголовок и подитоги. Внутри группы две строки с типом "Расчет" (назвать "Calc 1" и "Calc 2"). В формуле в первой просто прописать "1", во второй "2" (чтобы не возиться с данными для расчета отчета).
5. Построить отчет и убедиться, что он выглядит следующим образом:

Name.................Value
Group
Calc 1................1
Calc 2................2
Group.................2

Итог по группе должен быть 3.

Если в группе были бы строки с типом не "Расчет", а поместить туда какой-нибудь счет ГК настоящий (для сбора текущих одоротов), то подитог посчитался бы верно.

Если будет хотфикс, поделитесь, пожалуйста.

[mazzy]

пожалуйста, прекратите все валить в одну кучу.
если хотите сообщить другим участникам об ошибке, то создавайте новые темы, не забывайте добавлять теги "баг" и "ошибка".