1C торговля доступ через терминалы

[www2000]

Еще одну вещь вспомнил, вот на этих выходных подъехал к клиенту: запросы к регистрам выполнются на раз 5-ый, а иногда и реже. База стоит локально, никакие перендексации и другие процедуры не помолги, пока я не зашел во временный каталог пользователя в Документ енд сеттингс, где было обнаружено около 35 000 временных файлов созданных 1С. После их удаления все заработало как часики, даже без переиндексации. Может тоже что-то подобное творится на пользовательских компьютерах. Обычно эти файлы накапливаются при сбойном закрытии 1С. Проверь работу УПСов и состояние электрической сети.

[SRT]

Придерживаюсь мнения, уже высказанного в (8). Здесь проблема не только в 1С. У windows рыльце тоже в пуху. Если проблема только в 1С или в ее тормознутости из-за перекатывания большого объема данных на раб. станцию то, согласитесь, скорость работы подключения по сети должна мало отличаться, когда работет только это подключение и когда на машине файлового сервера консольно запушен еще один сеанс 1С. Я говорю НЕ о монопольном режиме. Просто на сервере запущена 1С и пользователь ее не сильно грузит. Так вот, во втором случае скорость работы по сети может стать в разы хуже. Если интересно - найду ссылку в подтверждение моих слов и выход только один - терминал. ТАм не требуется сетевое кеширование. Самое смешное, что если на сервере стоит жесткий диск с большим объемом кеша, то этот эффект не заметен. Мы долго не могла поянть, почему нет повторяемости проблемы. Почему не могу дать ссылку сразу? - да просто это решение принято 3 года назад и мы к нему не возвращаемся после того, как выяснилось, что win2003 эту проблему не решил. Ссылку потерял. Но найду, если очень нужно.

[Beetle]

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

Подумайте хорошо, каким макаром синусоидальная наводка в 50Hz помешает 10мбитному потоку. Почему появлялась проблема с коаксиалом, вы, судя по всему знаете, так ?

Удивительно, как вы сделали такой вывод обо мне?

У вас удивительно теоретические рассуждения.

И хотя я с вами до сих пор не углублялся в то, о какой версии 1С идет речь, но рискну на этот раз раз сам выяснить о чем вы?

Вообщето версия 7.7 (7.x ? - вряд ли меньше 7.7) явно задана автором треда. Или вы знаете продукт 1С:Торговля версии 8.0 ?

Я так понял, что вы приводите в вину 1С 7-ке то, что там зачастую при формировании отчетов и других операциях, обработке подлежит большое число данных, - целиком загружаются в оперативную память таблицы данных?
И ваша проблема - выбросить пользователю сотни мегабайт таблиц через сеть для обработки и формирования отчета у него.
Я верно развернул мысль?

Добавьте "многократно" и "крайне неоптимально" и будет практически все верно. Движок и работа с данными у 7-ки очень далеки от совершенства. Например при реиндексации прочитанные данные с диска превышают объем базы раз в 5, а объем записанных превышает размеры индексов раз в 10. И проблема даже не в отчетах. Если нужно получить большой и сложный отчет можно и подождать. Проблема в оперативном подтягивании справочников, журналов и так далее при обычной работе. Задержка даже в полсекунды при рутинной операции воспринимается субъективно как жуткое торможение.
Ну а с ростом объема данных увеличиваются и чисто вычислительные затраты. Многие ресурсоемкие вещи гораздо быстрее делаются на хорошем сервере, но это уже дело такое.

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

Базе 7 лет. Когда она была основана на какой-то типовой конфигурации, да, но с тех пор много воды утекло. Фактически это очень большая самописная конфигурация. Базой занимается программист (не я). Который уже года два-три предлагает не мучаться с 10 гиговым угробищем на дбфах, но переход хотя бы на SQL не говоря о 8-ке чреват многими вещами, в т.ч. чисто административными, так что вопрос пока висит и используются полумеры типа порезки базы и так далее.

Я эту базу видел и так сказать "держал в руках". Поэтому говорю о том, что знаю. А Вы - теоретизируете.

Здесь мне придется вернуться к страницам оранжевых библий.. или можно обратиться на страницы фирмы 1С:
http://www.1c.ru/rus/products/1c/predpr/default.jsp

И ? Единственная клиент-серверность для 7-ки это вынесение SQL сервера на другую машину. В данном случае имеем дело не с SQL базой. Клиент-сервер это уже 8-ка.

Между тем, за годы жизни семерки образовались различные дополнительные продукты, например DBEng32:
http://1c.proclub.ru/modules/mydownloads/personal.php?cid=143&lid=7456
Они позволяют на клиент-серверную часть взглянуть еще шире.

А смысл ? Вы думаете у этой компоненты будет меньше проблем по переходу, чем у SQL-версии ? Хотя надо почитать, спасибо, возможно оно даст какие-то выигрыши и при использовании в терминале, если не решится вопрос с переходом на SQL.

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