Учет под SQL2005 - больше часа

[dmites]

работали под 3.7 на SQL2000 - норм
на новый сервер поставлили SQL2005
развернули базу, решили все проблемы с сессиями, правами и т.п.
пробуем учитывать документ - думает около часа
SQL монитор говорит, что при учете в 22 CU команда find('+') вызывает
запрос select * from Item Ledger entry
которая выполняется непонятно почему 40-50 минут
затем то же с Value Entry
пробовали на 4.0, оптимизация ключей не помогает
в чем проблема ???

[Arshak]

в 4-0 sp-1-2 основная оптимизация под SQl заключалась в замене
find('+') на Findlast b find('-') на Findfist. в 3-70 , на сколько я помню их нет, но вероятно если перейти на оболочку 4-0 то и в коде 3-70 можно использовать эти функции.

[Dzemon]

Переходите на 4-ку СП2.

[dmites]

локализовали проблему:
при фильтрации по 1-му из полей Code10
(есть вторичный ключ)
Sql надолго уходит в себя...
rIle.setcurrentkey(field1);
rILE.setrange(field1,'ЦО');
примечательно что при фильтрации по другому абсолютно аналогичному полю все в порядке
ключ оптимизировали,убивали создавали т.п.

[dmites]

оболочка 4sp2
база 3.60

[dmites]

ситация проясняется
для Navision setcurrenkey не прямое указание на использование данного ключа при SQL-запросе, а не более чем
"order by" то есть sql по своему усмотрению выбирает нужную ключ
при построении плана запроса, где более важную роль играют поля по котрым накладывается фильтр. в результате при наличии вторичных ключей по аналогичным полям, setrange по 1 полю выполняется с использованием его индекса (Sql так решил), а в другом с использованием первичного кластерного ключа из-за чего
такая разница в обработке.
FindLas и find('-') на время существенно не повлияли

[dmites]

лечится
в 4 ссделали кластерный ключ не первичный Entry_No а
вторичный Field1,Entry_No
в результате sql стал использоваеть его при выше указанном запросе
и всё стало на свои места....

[Wizard_imported]

setcurrenkey убрать нельзя? в такой конструкции

Цитата:

rIle.setcurrentkey(field1);
rILE.setrange(field1,'ЦО');

в SQL версии эта команда бесполезна, если не вредна.

ну и не то чтобы совсем уж плохо, но менять кластерность на первичных ключах у книг нехорошо. ИМХО... Уж лучше пусть никакой ключ не будет кластерным чем такой...