Часто доводиться бачити здивування користувачів з приводу повільної роботи конфігурацій на базі 1С 7.7 в мережевому варіанті. У найпростішому випадку організація роботи в мережі полягає в тому, що на комп'ютері, де знаходяться дані, відкривається доступ до папки з базою по мережі, потім на інших комп'ютерах налаштовується підключення до цієї мережевий папці. Корінь проблеми в цьому випадку в тому, що коли клієнтський комп'ютер відкриває базу по мережі він запитує доступ відразу до всіх файлів бази, тобто для стандартної Бухгалтерії це буде близько 250-ти файлів. Далі, при виконанні розрахунку залишків або оборотів в звіті або при проведенні документа, клієнт закачує собі повністю файли даних для виконання розрахунків. Саме ці маніпуляції з файлами сильно гальмують роботу додатка, особливо це помітно у випадках з розрахунковими числами в списку довідника - наприклад стовпець із залишком товару. Що можна зробити?
Найдієвіший спосіб збільшення швидкодії - переклад клієнтів в режим використання термінального сервера. Для цього на центральному комп'ютері, на якому знаходиться база даних, повинен бути встановлений сервер терміналів, інші комп'ютери підключаються до сервера використовуючи програму-клієнт. Крім збільшення швидкодії є ще одна особливість такого формату роботи: можливість встановити один потужний сервер і використовувати на робочих місцях дешеві комп'ютери, від яких вимагається тільки запуск клієнтської програми. Клієнтський комп'ютер виглядає приблизно так:
Позмагатися з термінальним режимом може тільки тонка настройка програми: добитися нормальної швидкості роботи програми можна проаналізувавши код, виявивши слабкі місця, проте швидше за все при цьому доведеться відмовлятися від зручностей - не відображати залишки в динамічних списках, які не розфарбовувати рядки, не відображати розрахункові ціни і т .п. Іноді можна вирішити проблему повністю змінивши програму, наприклад, написавши для окремих користувачів окремий робочий модуль: відділ у магазині працює зі своїм складом і веде відпуск товару, можна на початку дня сформувати залишки для цього відділу, зберігши їх в тимчасовій таблиці, відділ протягом дня оформляє документи, які в своїх розрахунках використовують і змінюють ці тимчасові залишки і не проводять розрахунки в основній базі, в кінці дня результат роботи перевантажується в основну базу і остаточно проводиться за обліковими регістр м. Такі методи вимагають інших витрат - роботи програміста. Ще один метод повного поділу бази стандартними засобами - розподілені бази. Але в обох випадках втрачається іноді дуже критична для повноцінної роботи складова - достовірність оперативних даних. При поділі бази на здебільшого не буде видно реальну картину обліку поки окремі здебільшого не будуть синхронізовані.
Не можна не згадати ще один дієвий спосіб - змінити формат зберігання даних помістивши дані на SQL сервер. Це рішення дороге, проте без нього не обійтися якщо база об'ємна, кількість користувачів велике і інтенсивно вводяться нові документи. Одним з важливих плюсів використання SQL сервера можна вважати захищеність даних. Наприклад, можливість захистити базу від копіювання цікавими користувачами - в звичайному файловому варіанті встановити такий захист неможливо.
Ну, а може вам просто потрібно провести заміну мережевого обладнання? Замінити мережеві плати і хаби на підтримуючі швидкість передачі даних до 1 гігабіта / с. Однак врахуйте, що це рішення буде тимчасовим, до того часу поки обсяг даних не виросте і доведеться шукати нове рішення. Хоча, я знаю клієнтів, які роблять "урізання" бази кожні 2-3 місяці.
На практиці зазвичай доводиться застосовувати деяку комбінацію наведених рішень: необхідно і програму перевірити, і переконатися, що мережа в порядку, і сервер перевірити.