Было проведено ряд тестов с поставщиком ТП -  ODBCDataBase. Было выяснено, что испольование GROUP BY приводит к вылету ТП (подключение занято до получения ...). Использование View в качестве источника для запроса - также не решало проблему, ошибка та же.
Есть пару предложений по этому поводу.
1 - Для "ТаймаутОбновления" сделать какую то предопределенную процедуру, которая будет вызываться перед обновлением (например, если источник ТЗ, то чтобы обновить данные в ТЗ).
2 - Не делать столь жесткими условия по GROUP BY, потому как иногда надо все таки в запросе эта конструкция, а иногда приходиться использовать и With ROllup, уже не знаю что будет с ним, как поведет себя ТП.

Ага , только так вся идея ТП идёт лесом, для получения 20 строк данных приходится  обрабатывать все

artbear писал(а) 08. Сентября 2008 :: 09:51:


Когда происходит скролирование ТП то происходит выборка только нескольких строк - необходимых для отрисовки ТП. А в случае с под запросом сервер у тебя будет лопатить все записи а потом уже их отфильтровывать. Т.е. если запрос "тяжёлый"  будут тормоза.

orefkov писал(а) 09. Сентября 2008 :: 06:11:


Вот я об этом и говорю, только если бы еще и обновлять эти данные в ТЗ как то когда происходит обновление источника ТП, было бы проще немножко с реализацией.

pvase писал(а) 09. Сентября 2008 :: 15:13:

Когда используется локальный поставщик данных (данные не могут изменяться другими процессами, например поставщик ТЗ), использовать ТаймаутОбновления смысла не имеет.

Если нужно периодическое обновление самих данных в ТЗ, это нужно делать функционалом формы: ОбработкаОжидания(), с подачей команды обновления отображения ТП (ТП.ОбновитьСтроки()).

Я в свое время продумывал механизм своеобразной подписки на события. Т.е. если мы в запросе используем определенную таблицу, то подписываемся на изменения в ней, когда другой процесс внесет изменения в эту таблицу, происходит уведомление подписчиков на необходимость обновления данных. Подписчики, в свою очередь, обновляют свои отображаемые данные.