Конфигурация на основе компоненты "Оперативный учет"

Помогите пожалуйста, такая проблема. Написала не очень сложную конфигурацию на основе Оперативного учета, в отчетах пользовалась в основном запросами. Справочник контрагентов большой, порядка тысячи или даже больше. База лежит на сервере. Работают три пользователя. Когда один монопольно, все нормально, когда они все, то тормозит жутко. Ну я бы еще поняла, если бы при формировании отчетов. Она тормозит при выборе контрагента(!). Еще у них стоит упрощенка (Бухгалтерский учет), там при том же примерно количестве контрагентов все в порядке, никакого торможения. Может кто сталкивался, в чем дело? Что я не так сделала или что яне сделала? Помогите пожалуйста, заранее всем спасибо за ответы. Злата

Не знаю, у кого как, а у меня все самописки на основе бухгалтерского учета. Оперативный учет и расчет - давольно непредсказуемые компоненты.
У нас обычно, если используют оперативный учет, то ставят терминал. Иначе по сети тормоза жуткие.
В обыкновенной стандартной торговле - расходная накладная открывалась 1-2 минуты!!! После 1 года работы. Под терминалом всё заработало нормально.
Вероятно у Вас, в справочнике "Контрагенты" используется какой-то расчет оперативных итогов при открытии? Если да, тогда конечно, программа упадет на "ручник".

А еще пользователи на меня ругаются, говорят, что надо было "Торговлю и склад" ставить... Хорошо, а может кто знает, с чем едят Транзакции? Как их использовать и может ли это мне помочь? А еще такой вопрос, влияет ли на быстродействие авторизация? В моем случае пользователи не авторизуются, ходят все как один ((((???? Заранее спасибо за ответы. Злата.

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

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

так сложно ответить....
а если заходит один, но не монопольно?
а если монопольно, но с любой машины все нормально?

попробуйте так:
в режиме предприятия:
сервис-параметры-закладка общие
поле "период опроса изменений БД"? установите МИНИМУМ 30 сек.

Спасибо огромное, а что, 30 сек - это оптимальное время? А что насчет "Время ожидания захвата"? Злата.

Зависит от сетки. Каждые 30 сек информация на клиентских машинах обновляется. Например: один юзер поменял справочник, остальные об этом узнают самое позднее через 30 сек. Если время меньше - остальные узнают быстрее, но и сеть нагружена будет больше.
Время ожидания захвата - это время, в течении которого система пытается захватить файл для транзакции. Пример: проводим документ. Во время проведения документа другие документы проводить нельзя, даже в режиме раздельного доступа. Если кто-то захочет провести другой документ - система ждет пока проведется первый. Время имеет смысл увеличить если часто вылетает ошибка "Ошибка захвата таблицы ХХХ".

Спасибо большое. В самом справочнике убрала вычисление остатков по каждому контрагенту. А вот, что делать с отчетами, как их "разогнать", ума не приложу (((( Поступило предложение поставить SQL сервер, но что то я думаю ради трех машин.... А вы как думаете, стоит?

Вот видите - ларчик просто открывался...По личным наблюдениям, большинство тормозов в различных справочниках были вызваны расчетом различных остатков по текущему элементу. Я поступал так: создавал отдельную форму списка (максимально легкую) и использовал ее там, где нужен был быстрый выбор элемента справочника.

Про тормозящие отчеты по-подробнее можно? Что за отчет? Какую информацию выводит? Откуда данные берет? Каким способом?

P.S. - На мой взгляд для 3х пользователей SQL добавит лишь СТАБИЛЬНОСТИ, однако потребует ОТДЕЛЬНОЙ, не самой слабой машины.

"Конфигурация довольно простая, во всех отчетах использую запросы, например  Взаиморасчеты с покупателями:
ТекстЗапроса=
"//{{ЗАПРОС(Оборотка)
|Период с Начдата по Кондата;
|Клиент = Регистр.ВзаиморасчетыСПокупателями.Контрагент;
|Сумм= Регистр.ВзаиморасчетыСПокупателями.Сумма;
|Функция НачОст=НачОст(Сумм);
|Функция КонОст=КонОст(Сумм);
|Функция Прих = Приход(Сумм);
|Функция Расх=Расход(Сумм);
|Группировка Клиент;
|"//}}ЗАПРОС
;
 
Или например Отчет по оплате, в отличие от предыдущего  он "по документам":

ТекстЗапроса=
"//{{ЗАПРОС(Оплата)
|Период с Начдата по Кондата;
|ОбрабатыватьДокументы Проведенные;
|Докум = Документ.Оплата.ТекущийДокумент;
|Склад = Документ.Оплата.Склад;
|Клиент = Документ.Оплата.Контрагент;
|Товар= Документ.Оплата.Товар;
|Колво= Документ.Оплата.Количество;
|СуммаВсего=Документ.Оплата.Сумма;
|Функция СумВсего = Сумма(СуммаВсего);
|Функция Колич=Сумма(Колво);
|Группировка Докум;
|Группировка Клиент;
|Группировка Товар;
|Условие(Склад = ВыбСклад);
   |"//}}ЗАПРОС
;

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