[Ravennt]

dtmdlMain.ibqryViewUsluga.Locate('USLUGA_ID',uslID ,[]);
frmMain.dbgrdhMain.SetFocus;

uslID - номер строки на которую нужно перейти

если быть точнее в базе сейчас 532 записи

[Страдалецъ]

Повторно задаю вопрос. Индекс есть по Usluga_ID в базе?

[Freeman]

Сообщение от Страдалецъ

Повторно задаю вопрос. Индекс есть по Usluga_ID в базе?

Еще раз предлагаю посмотреть на реализацию TIBCustomDataSet.Locate и убедиться, что индексами там и не пахнет. Какие индексы на клиенте??

[Ravennt]

Сообщение от Страдалецъ

Повторно задаю вопрос. Индекс есть по Usluga_ID в базе?

индекс по Usluga_ID в базе есть!!

Проблема решилась и оказалась своеобразна!!!! при запросе

Код:

select 
    group_table.organiz,
    group_table.kolvo_clients,
    usluga_table.pdate,
    usluga_table.time_start,
    usluga_table.time_end,
    usluga_table.target_name,
    summa_table.summa_doc,
    status_table.fstatus,
    usluga_table.kolvo_uslug
from usluga_table
   inner join summa_table on (usluga_table.summa = summa_table.summa_id)
   inner join status_table on (usluga_table.status_usluga = status_table.status_id)
   inner join group_table on (usluga_table.group_usluga = group_table.organiz_id)
where usluga_table.group_usluga <> 0
order by usluga_table.pdate, usluga_table.time_start

проиндексировал поля отвечающие за сортировку дополнительно
usluga_table.pdate
usluga_table.time_start

ПРОБЛЕМА РЕШЕНА!!! Всем спасибо за помощь!

[Ravennt]

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

Еще раз предлагаю посмотреть на реализацию TIBCustomDataSet.Locate и убедиться, что индексами там и не пахнет. Какие индексы на клиенте??

индексы в базе ставятся, субд их сама обрабатывает

решение указано выше

[Freeman]

Быдлокодеры хреновы, что Ravennt, что Страдалецъ, даром что модератор. Уж извините за прямоту.

Говорил же: отладчиком смотрите! Тормоза наверняка были из-за самого запроса, а не сканирования каких-то сраных 500 записей на клиенте.

[Ravennt]

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

Быдлокодеры хреновы, что Ravennt, что Страдалецъ, даром что модератор. Уж извините за прямоту.

Говорил же: отладчиком смотрите! Тормоза наверняка были из-за самого запроса, а не сканирования каких-то сраных 500 записей на клиенте.

Я самоучка нигде не учившийся просто по книжкам, поэтому и спрашиваю.
при отладке именно на Locate все вешалось! Из-за сортировки запроса Locate и выполнялся долго. Если уж не хватает знаний, мне казалось для этого и нужны форумы, чтобы можно было спросить или прочитать уже решения, если у кого то такая проблема появлялась.

Сразу суперпупер программистом не становятся все с чего нибудь начинают. И еще вопрос СПЕЦИФИКИ. каждый специализируется на своем.

[Freeman]

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

при отладке именно на Locate все вешалось! Из-за сортировки запроса Locate и выполнялся долго.

Хоть и тяжело заниматься удаленной отладкой через форум, но я по-прежнему уверен, что замедление Locate -- наведенная ошибка, а истинная причина была в чем-то другом. Еще раз предлагаю посмотреть в код TIBCustomDataSet.InternalLocate и убедиться, что там выполняется обычное сканирование, лишь немного сложнее кода самописной процедуры LocateTable, представленной несколькими постами ранее.

Предлагаю для теста удалить индекс, но после открытия запроса вручную выполнить FetchAll и посмотреть, будет тормозить на Locate или нет. По логике вещей тормозить должно на FetchAll.

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

Сразу суперпупер программистом не становятся все с чего нибудь начинают.

Чтобы стать профессионалом, нужно учиться. А если ставить заплаты не вникая в суть, можно стать только профессионалом в наложении заплат. Мне кажется, что это не тот профессионализм, к которому нужно стремиться.

[Страдалецъ]

Чтобы стать профессионалом, нужно учиться.

Когда учатся становятся учеными, а что бы стать профессионалом, надо по професси работать.