![]() |
|
Комплексная автоматизация Все, что связано с совместной работой нескольких программ (1С и не только), вопросы эксплуатации и внедрения. |
![]() |
|
Опции темы | Опции просмотра |
![]() |
#1 |
Member
Регистрация: 01.02.2009
Сообщений: 52
Поблагодарил(а): 3
Благодарили 5 раз в 5 сообщениях
![]() |
![]()
Владеем лицензией на сетевую версию 1C Предприятие 7.7 для SQL.
Работаем в стандартной бухгалтерии, с ней проблем нет, а вот с управлением складом и производством есть проблемы (конфигурацию создала Анди специально для нас) после введение нового модуля база стала немного притормаживать. Главная причина - это конечно, то что, с введением этого модуля увеличилось кол-во пользователей, активных пользователей которые постоянно вносят информацию 3 и еще иногда в течение дня для получения актуальной информации подключаются еще 2-3 пользователя и тогда журналы начинают немного притормаживать в принципе все отчеты работают нормально, а вот длинные журналы явно тормозят. Используем мы файловую базу данных на Windows 2003 сервер Intel Xenon 2*2.4Ghz 2GB RAM 1Gb/s to switch 3COM, 100Mb/s to clients вопрос такой нужно ли в данной ситуации переходить на MSSQL если да, то какие расходы у нас появятся, без проблем ли переконвертируется база данных, какие могут быть еще проблеммы?. В принципе в будущем кол-во пользователей будет только расти. Последний раз редактировалось ANDI_Hotline; 11.03.2009 в 22:36. |
![]() |
![]() |
![]() |
#2 |
Hotline
Регистрация: 01.01.2006
Сообщений: 476
Поблагодарил(а): 8
Благодарили 49 раз в 37 сообщениях
![]() |
![]()
Возможно, причина в том, что в журналах, при просмотре, происходят какие то либо вычисления, с обращениями к базе данных. Необходимо анализировать в каких журналах и какое замедление случается. Просьба уточнить.
Про переход на SQL. 3-6 пользователей для файловой версии 1С:Предприятия 7.7 является слабой нагрузкой, до 10-15 активно работающих пользователей может работать без проблем. Да и 10 лет (!) назад, когда фирма 1С разрабатывала платформу 1С:Предприятие 7.7 такой техники, как сейчас, практически не было. В случае, если есть конкретные "узкие места", по быстродействию, часто имеет смысл оптимизировать программный код, а не переходить на SQL. MS SQL денег стоит, причем не малых. Если он уже на предприятии приобретен, тогда лучше базу на SQL перевести. Если база данных нормальная, т.е. без нарушения логической и физической целостности, то это сделает платформа 1С:Предприятие 7.7, а если есть проблемы, то и руки приложить придется... |
![]() |
![]() |
![]() |
#3 |
Member
Регистрация: 01.02.2009
Сообщений: 52
Поблагодарил(а): 3
Благодарили 5 раз в 5 сообщениях
![]() |
![]()
Я думаю Вы правы в одном из журналов который был основным тормозом призоводится дополнительная обработка, разработчик программы - Дмитрий со мной уже связался.
Надо было конечно сразу ему писать ![]() Ну будет другим заказчикам наука не перегружать журналы ![]() |
![]() |
![]() |
![]() |
#4 | |
Senior Member
Регистрация: 18.01.2009
Сообщений: 637
Поблагодарил(а): 39
Благодарили 78 раз в 63 сообщениях
![]() |
![]() Цитата:
Точна также нельзя перегружать форму списка справочника. Нельзя делать огромные табличные части документов. Большие таблицы значений, во время их формирований или других действий над ними, надо временно прятать, сделать видимость(0). Если имеете WINDOWS 2003, не пользуйтесь им как обычным файловым сервером, запускайте его как сервер терминалов. Скорость работы у каждого сетевого пользователя, будет равна скорости работы локального пользователя. И т.д. ... ![]() |
|
![]() |
![]() |
![]() |
Здесь присутствуют: 1 (пользователей: 0 , гостей: 1) | |
|
|