народ кто нить реально без проблем переписывал какой нить журнал на ТП+Запрос или еще что?
смысл вот в чем, есть журнал переписанный в ТП+Запрос, еще там есть поле так сказать расчетное с формулой как у обычных журналов (данные этой колонки получаю параметаризированым запросом) отсюда 2 не хороших и не приятных момента:
1. при бегании мышкой или стрелкой клавы по списку документов в ТП при переходах от видимой области к следующей на секунды 2 тормозит и естественно раз юзер жал на стрелку клавы в итоге резко перелетает на пол страницы вниз.
2. более серьезный на мой взгляд момент, когда документ человек проводит родной журнал тутже засекает его статус и выставляет значек проведение или удаления и т.д. в ТП же все работает ровно так как журнал у соседнего юзера, все появляется только после периода обновления ТП, что зачастую юзера вводит в ступор при быстрой работе

Есть у кого какие идеи на этот счет?

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

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

vandalsvq писал(а) 01. Декабря 2009 :: 06:02:



Как то так и оно вызывается в ПривыводеСтроки():

Процедура ПодготовитьПарамЗапрос()

	рс2=СоздатьОбъект("ODBCRecordSet");
	рс2.ДобПараметр(1,14,8,0);
	рс2.ДобПараметр(1,14,4,0);
	рс2.ДобПараметр(1,14,9,0);
	рс2.ДобПараметр(1,14,9,0);
	ТекстЗапроса="-- Получить Сумму Кассового отчета по старой схеме
		|select top 1
		|	case when (sum($КассаСтроки.Сертификат)=0) then cast(sum($КассаСтроки.Выручка)-sum($КассаСтроки.СуммаВозврата) as char) else '*'+cast(sum($КассаСтроки.Выручка)-sum($КассаСтроки.СуммаВозврата) as char) end as КассовыйОтчет
		|from _1sjourn as jur (nolock)
		|	left join $ДокументСтроки.КассовыйОтчет as КассаСтроки (nolock) on jur.iddoc=КассаСтроки.iddoc
		|where (jur.iddocdef=$ВидДокумента.КассовыйОтчет)
		|	and (left(jur.date_time_iddoc,8)=?)
		|	and (substring(jur.$ОбщийРеквизит.ОтборДока,2,4)=?)
		|	and (jur.$ОбщийРеквизит.Фирма=?)
		|	and ($КассаСтроки.Секция=?)
		|	and (jur.closed &1=1)
		|";
	рс2.Подготовить(ТекстЗапроса);

КонецПроцедуры // ПодготовитьПарамЗапрос
 

vandalsvq писал(а) 01. Декабря 2009 :: 06:13:


Как раз так и сделано, он может сам рулить но не ниже 10 сек обновления, но народ быстрее работает и после проведения документа не видя что он провелся заходят и снова тыкают и так очень долго, и начинают звонить мол тот журнал был удобнее хоть и открывался сначала долго, а этот тормознутый (хотя оно просто по времени обновляется) но для юзера это тормоза типа

Запрос конечно тоже "не ахти". Условие по реквизиту многострочной части не очень "Приятно", поскольку никакого индекса там нет, и не будет если конечно ты не менял механизм 1С.
Как вариант я бы рассмотрел возможность выполнения запроса во временную таблицу с присоединением ее к журналу документов, с кнопкой на форме "пересчитать". Поскольку с точки зрения производительности это будет точно лучше, хотя возвращаемся к нашим "старым" баранам (п.1).
Думать надо... время поджимает

vandalsvq писал(а) 01. Декабря 2009 :: 06:25:


Понимаешь с кнопкой точно не айс и не проканает у нас, а уйти от строк тоже не получится так как все как раз там относительно этих строк, тоесть есть секции по которым заносятся ОтчетыРО, а КассовыйОтчет у нас один и там просто в каждой строчке своя секция по деньгам

pavlo писал(а) 01. Декабря 2009 :: 06:15:


запрос очень "плохой" Если переписать запрос будет работать
гораздо быстрее.
для начала поставь нормальное условие по дате без left

vandalsvq писал(а) 01. Декабря 2009 :: 06:39:


Ради одного журнала мутить такое не хотелось бы