[Pustik]

У нас есть тестовая база со стандартной логикой. Залили туда некоторые данные из рабочей. Открыл форму "Проекты". И вспомнил как мы столкнулись с жуткими тормозами на этой форме при переходе на АХ2009. При открытии формы "Проекты" на тестовой базе тормоза наблюдаются, но не такие заметные, так как данных мы залили не много. А на рабочей с реальными данными просто жуть.
А все потому, что в табличке ProjTable есть метод:

public boolean trxExists()
{
    ProjId                  projId = this.ProjId;
    boolean                 ret = true;

    ProjJournalTrans        projJournalTrans;
    LedgerJournalTrans      ledgerJournalTrans;
    InventJournalTrans      inventJournalTrans;
    ProjTransPosting        projTransPosting;
    SalesLine               salesLine;
    PurchLine               purchLine;
    SMAAgreementTable       smaAgreementTable;
    SMASubscriptionTable    smaSubscriptionTable;
    ProjRevenueTrans        projRevenueTrans;
    ProjOnAccTrans          projOnAccTrans;
    SMAServiceOrderLine     smaServiceOrderLine;
    PurchReqTable           purchReqTable;
    PurchRFQCaseTable       purchRFQCaseTable;
    ;

    if (this.Header == NoYes::No)
    {
        if(((select firstonly projJournalTrans      where projJournalTrans.ProjId        == projId).RecId == 0) &&
           ((select firstonly ledgerJournalTrans    where ledgerJournalTrans.AccountNum  == projId &&
                                                          ledgerJournalTrans.AccountType == LedgerJournalACType::Project).RecId == 0) &&
           ((select firstonly inventJournalTrans    where inventJournalTrans.ProjId      == projId).RecId == 0) &&
           ((select firstonly projTransPosting      where projTransPosting.ProjId        == projId).RecId == 0) &&
           ((select firstonly salesLine             where salesLine.ProjId               == projId).RecId == 0) &&
           ((select firstonly purchLine             where purchLine.ProjId               == projId).RecId == 0) &&
           ((select firstonly smaAgreementTable     where smaAgreementTable.ProjId       == projId).RecId == 0) &&
           ((select firstonly smaSubscriptionTable  where smaSubscriptionTable.ProjId    == projId).RecId == 0) &&
           ((select firstonly projRevenueTrans      where projRevenueTrans.ProjId        == projId).RecId == 0) &&
           ((select firstonly projOnAccTrans        where projOnAccTrans.ProjID          == projId).RecId == 0) &&
           ((select firstonly smaServiceOrderLine   where smaServiceOrderLine.ProjId     == projId).RecId == 0) &&
           ((select firstonly purchReqTable         where purchReqTable.ProjId           == projId).RecId == 0) &&
           ((select firstonly purchRFQCaseTable     where purchRFQCaseTable.ProjId       == projId).RecId == 0) &&
           (!this.AssetId))
        {
            ret = false;
        }
    }
    else
    {
        ret = false;
    }

    return ret;
}

он дергается из метода на форме setFieldAccess(), а этот, в свою очередь, стоит в методе active() у главного датасоурса: ProjTable.
Сразу скажу, что мы приняли решение во все таблицы добавить индех по полю ProjId, а в таблицу LedgerJournalTrans по AccountNum,AccountType.Скорректировали запросы в этом методе на IndexHint и все зашуршало.
В основном тормоза были на таблицах projJournalTrans,LedgerJournalTrans,inventJournalTrans,SalesLine,PurchLine. Эти таблицы, можно сказать являются справочниками-черновиками. Вся главная информация лежит в проводках. И у меня возникает вопрос: разработчики не обратили на скорость внимание рассчитывая на то, что черновики периодически должны чиститься или просто не подумали? Но главный вопрос вообще о целесообразности чистки черновиков. Кто-нибудь чистит эти таблицы? У нас эти таблицы не чистятся. Записей очень много.
PS: Тему может быть неудачно назвал. Но ведь можно было назвать и так "Чистка черновиков и Экономия место БД" или как-то еще. Решил так как есть, так как задумался об этом на форме.