В последнее время у некоторых пользователей при работе стала возникать ошибка захвата на чтение некоторых таблиц,вследствии чего пользователь отваливается с несохраненными данными.Конфигурация самописная похоже на зарплате, работала 5 лет без изменений. Есть идеи как решить проблему? [Ответ]

Сообщение от :
Есть идеи как решить проблему?

Оптимизацией. Пути ее разные. Смена типа базы (SQL, DBF). Апгрейд железа. Вызов программиста.

Ты ситуацию подробнее опиши. На каком железе, сколько пользователей. Терминал сервер используете? [Ответ]

Сервер windows_2000 около 50 пользователей (1С), одновременно работают около 20(в этой базе 1С), база DBF, через терминал только я работаю,обьем базы 63 Mb,база заточена под электронный документооборот(письма).Сам грешу на сеть или на комп одного из юзеров. На сервере сейчас около 80 пользователей (вместе с 1С). [Ответ]

Заметил подобные глюки при работе юзверей со встроенной в материнку сетевой картой. Стоило поставить всем писиайные карточки - проблема ушла.
Специально проверял - возврат на встроенную карточку приводит к появлению глюков... Причина явления мне не понятна [Ответ]

<fpfFT_ZS, База маленькая. Тогда сгоняй всех под терминал и забудь. [Ответ]

Попробую на терминал. Спасибо. [Ответ]

Сообщение от FT_ZS:
Сервер windows_2000 около 50 пользователей (1С), одновременно работают около 20(в этой базе 1С), база DBF

вот в этом то и траблема. [Ответ]

ИМХО, переход на SQL в данном случае не решает всех ситуаций. Если юзер формирует отчет, лопатящий кучу документов, а в это время другой юзер работает с этим видом документа, то ситуация повторится не зависимо от того файл-сервер это или SQL, терминал тоже подобных траблов не решит, еще и геммор появится с тем что памяти на терминале под каждый сеанс надобно метров 200 по моему... Решается такая байда двумя способами -либо переписывать отчеты так чтобы лопатились тока регистры и бухитоги, либо кластеризировать конфу. [Ответ]

Ыщккн, век живи век RTFM все равно LMD
на каждый сеанс в терминале выделяеться системой около 20 метров памяти + столько сколько запросит процесс.. для 1С это около 30 метров. Из опыта работы 2 гига оперативки достаточно для 30 -50 станций...

Сообщение от Ыщккн:
Если юзер формирует отчет, лопатящий кучу документов, а в это время другой юзер работает с этим видом документа, то ситуация повторится не зависимо от того файл-сервер это или SQL

внимательно читаем техдоки к MS SQL...очень внимательно....

Сообщение от lordmb:
Вызов программиста.

Так ведь вызов аналитика для начальства дорого стоит проще сисадмина напряч пусть на форуме спрашивает [Ответ]

насколько я понял у тя 7.7 .переложи на сиквел, т.к. 1с в дбф при захвате блокирует целиком таблицу, в то время как на сиквеле - записи. терминал тут не сильно спасет, т.к. скорее всего работа нескольких пользователей будет пересекаться по таблицам [Ответ]

Сообщение от Sandy:
Ыщккн, век живи век RTFM все равно LMD
на каждый сеанс в терминале выделяеться системой около 20 метров памяти + столько сколько запросит процесс.. для 1С это около 30 метров. Из опыта работы 2 гига оперативки достаточно для 30 -50 станций...

Согласен. 20 метров. Давно не брал в руки шашек )

Сообщение от Sandy:
Ыщккн
внимательно читаем техдоки к MS SQL...очень внимательно....

Пардон. Давно не сталкивался с типовыми конфами. На нормально переработанной конфе возникает
соблазн писать рулесы к таблицам. И чего там только не пишут. [Ответ]

Сообщение от Ыщккн:
Давно не сталкивался с типовыми кон

конфа тут ни при чем просто специфика SQL серверов не допускает торможения системы сколько бы юзеров не работали с таблицами и что бы они там не делали ну если только ООООЧЕНЬ МНОГО.... [Ответ]

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

Сообщение от Sandy:
конфа тут ни при чем просто специфика SQL серверов не допускает торможения системы сколько бы юзеров не работали с таблицами и что бы они там не делали ну если только ООООЧЕНЬ МНОГО....

А кто говорит про конфу? Я говорил о рулесах. Вернее о сторедных процедурах где встречается TBALOKX. Например, такие конфы любил делать Rarus еще на семерке.

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

Так может дело не в бобине, если пересадка юзеров на другой адрес помогла? Может свичик поменять? [Ответ]

из за этого покупать не будут однозначно [Ответ]

Сообщение от FT_ZS:
из за этого покупать не будут однозначно

так енто один из самых дешевых вариантов.... причем свитчик можно купить с 1-м слотом на гиг, а в сервак карточку впихнуть на гиг... [Ответ]

Скорее откажутся от 1С и задачу переведут под Java [Ответ]

К тому же на сервере стоит гиговая карта и две по 100 [Ответ]

Сообщение от FT_ZS:
Скорее откажутся от 1С и задачу переведут под Java

И все таки несмотря на все свои трудности с начальствои и работой вообще, подними терминал, и переведи всех пользователей, использующих 1С туда. и забудешь про проблему. Иначе будешь неделями тестироватьвсе сетевые карты, потом провода, потом... будешь опять спрашивать что бы еще можно было бы потестировать... [Ответ]