Кстати, у моих клиентов было примерно то-же самое: конфигурация - переделанная бухгалтерия, операция с правильного документа приципилась на документ, вообще не имеющий операций. Разрулить получилось с помощью ТИИ и с помощью выгрузки/загрузки - оба действия дали положительный результат.

Neo писал(а) 19. Ноября 2009 :: 11:33:

Если все что Вы написали правда - Выкидывайте Ваш сервер или
у Вас жутко плохая сеть.

(Neo) Если хотите то опишите Ваш сервер как можно подробней
, ОС , SQL подробно разберем Вашу текущую ситуацию.

> Не верю.
Вы можете воспроизвести повторяемый глюк 1с ?

- Ну я же чуть выше привел пример с глюком метода Провести() с параметром. Когда началась эта проблема, мы поставили триггер на _1SSystem, собирали инфу. И в конечном итоге вышли на то место в коде, откуда скорее всего ноги растут. До написания этого кода ошибки такой никогда не было. После его корректировки ошибка полностью ушла. Однозначно это глюк 1С.

Вручную разумееся воспроизвести глюк не удавалось. Он бывает не часто, и только при одновременной работе > 100 пользователей.

Neo писал(а) 20. Ноября 2009 :: 07:03:

Смысл описывать старый сервер есть. Чтобы снять необоснованность глючности 1с. Сам подумай 1с77 наиболее
отлаженный программный продукт ( если память не изменяет 7.0 появился в сентябре 1996).
Также имеет смысл описывать чтобы старые ошибки (Неточности ) не перенести на новый сервер.

стоит sql2005 гороздо лучше чем sql2000.
sp на  sql2005 надо не ниже второго обязательно.
переписать подчиненные документы через прямой запрос.
в sql2005 исправлена ошибка с замедлением массового перепроведения( не нужен reconect).

sql2005 более интектуален чем sql2000 и его приводит в ступор плохая файловая система.
sql2005 пытается оптимизировать операции ввода вывода
(если файловая система плохая) у него это не получается и он
все время анализирует сам себя. Объяснение ненаучное но свое
основанное на своих шишках.

> Ну так приведите этот код до и после корректировки.

- Да все там очень просто. При закрытии документа при выполнении определенных условий создается новый документ (перемещение) и выводится вопрос - провести перемещение или нет.

Док=СоздатьОбъект("Документ.Перемещение");
---заполнение документа
Док.Записать();
Док.Провести(3); (если ответ на вопрос - "да").

Вот этот вариант в момент пиковых нагрузок сбивал ТА (обнулял).

В течение неск. месяцев искали причину (как временное решение - триггер, который откатывал транзакцию при обнулении ТА).

В итоге поставили Док.Провести(), и все, ошибка ушла, и уже больше года ее нет.

Neo писал(а) 20. Ноября 2009 :: 10:13:

Не все так просто как тебе кажеться.

Ну и попробуй расписать на бумаге что происходит при Провести(3). И раз Вы легко отказались от этого то это  было неправильное применение метода а не ошибка 1с.

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

Т.е надо было написать либо

ФлУСпех = 1;
Попытка
 Док.Записать();
Исключение
ФлУСпех = 0;
КонецПопытки;
Если ФлУСпех = 1 Тогда
Док.Провести(); // Еще более обезапаситься можно если  провести делать в Попытка
Иначе
// Обработка Ошибки Записать()
КонецЕсли;
 

Если все таки Вам нужен режим провести 3 то все это надо оборачивать во внешнюю транзакцию
т.е код

НачатьТранзакцию();
ФлУСпех = 1;
Попытка
 Док.Записать();
Исключение
ФлУСпех = 0;
КонецПопытки;
Если ФлУСпех = 0 Тогда
   ОтменитьТранзакцию();
   // обработка ошибки записать
  return;
КонецЕсли;
Попытка
Док.Провести(3);
Исключение
ФлУСпех = 0;
КонецПопытки;
Если ФлУСпех = 0 Тогда
   ОтменитьТранзакцию();
   // обработка ошибки Провести(3)
  return;
КонецЕсли;

ЗафиксироватьТранзакцию();
 

Кстати, в нашем случае Перемещение записывалось, но что-то сбоило при проведении