Рухнула база "Управление автотранспортом 3.0.6.3", платформа 1Ски - 8.1.15.14. Работает в файловом режиме. Лежит на сервере, куда юзеры заходят через терминалы.
Началось все с того, что у одного из пользователей (назовем его Иванов) один дописанный отчет работал не так, как у всех остальных. Т.е. из под всех терминальных сессий с заданным периодом, например, за сентябрь, отчет формируется верно, а именно из под терминальной сессии самого Иванова отчет формируется за весь период, как будто он не задан. !!! Первый раз встречаюсь с такой ситуацией. Какой-то глюк.

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

Сиптомы следующие: при загрузке в режиме "Предприятие" после ввода пароля просто выкидает и появляется стандартное виндовое окно "Обнаружена ошибка. Приложение будет закрыто. Отправлять не отправлять отчет". В конфигуратор база пускает. "Тестирование и исправление" также выкидывает на этапе "Проверка логической целостности". Пробовал отдельно реструктуризацию - тоже выкидывает. Реиндексацию только отдельно успешно проходит - но толку от нее нет.
Пробовал chdbfl.exe - грит "Ошибок не обнаружено".
Пробовал перенести на другую машину базу - тоже такие же все симптомы, выкидывает (т.е. дело не в кеше и не в компе).
Пробовал удалить проблемный отчет в конфигураторе - при обновлении конфы БД тоже выкидывает, при сохранении любых других изменений в конфе также выкидывает.

Прочитал полностью ветку
http://www.forum.mista.ru/topic.php?id=379784#this
также не помогло ничего вообще. Все также выкидывает.

Архив базы на вчерашнее утро есть, восстановлю, но обидно - потерян один день работы, и вообще, знать бы, как это вылечить, если вдруг повторится.

(0)размер базы?

(1)
160 Мб

Пока первым делом очень интересно было бы узнать, как вылечить базу.
Но если кто сталкивался с такими глюками с отчетами или другими объектами, дайте знать, пожалуйста.

попробуй. скопируй базу.  из  бэкапа возми конфу и загрузи(не объединение) в  копию?

тупо штатными средствами проверка диска делалась?

(4) сделал, при обновлении БД в момент "обработки структуры базы данных" опять выкинула как обычно
(5) сделал chkdsk, все ок на винте. Ошибок не обнаружено.
Но я ж сразу написал, что и на другом компе с платформой пробовал - также выкидывает.

Понимаю, что ситуация нестандартная. Но может кто сталкивался!

(0)
выгрузку/загрузку базы попробуй сделай в dt

может в клиент-серверный вариант загрузить попробовать? Просто уж больно на разрушение внутреннее похоже. Кстати, 40 метровая база сыпалась мгновенно, когда свет мигал, при этом производилась загрузка данных

(8) выгрузка/загрузка прошла без ошибок, но база опять вылетает. (

кеш почистить на Иванове не предлагали ?

(9)
попробовал, что в режиме конфигуратор, что в режиме предприятие выдает следующую ошибку "Ошибка при выполнении операции с информационной базой... Удаленный хост принудительно разорвал существующиее подключение"

(11)
да может и надо было это сделать перед тем как конфигурацию править.
Но уже поздно, база вылетает в любой сессии. И на другой комп с установленной локальной 1Ской уже переносил - все равно выкидывает.

up

160 mb? Только константы завели, что ли?

(14) а примерно так:
C:\Program Files\1cv81\bin\chdbfl.exe..

(15) Не, почему, уже заказов вбито куча и путевых листов (где-то 700 документов), и справочники транспортных средств полностью заполнены (где-то 100 элементов).

(16)
я писал в самом начале, chdbfl говорит, что ошибок не обнаружено.

ПередНачаломРаботыСистемы() - отладчиком попадает?

(19) Попробовал, не доходит.

Управление автотранспортом. Хм - а с ключами защиты там все ок?

(20) В журнале регистрации никакой информации ??

(22) + строка, которая завалила базу там тоже должна быть

плотформу попробуй другую, так из опыта ;-)

платформу*

(22) Журнал работает нормально в конфигураторе.
(23) Информации о какой-нибудь ошибке нету. Последняя существенная запись - это то, что конфигурация изменена, обновлена динамически. После этого уже база рухнула, и в журнале только отображаются после этого данные о запусках тестирования и исправления.
(24) 8.1.15.14 установлена - более старую что ли ставить? Не думаю, что есть смысл. Вот на старом компе еще попробовал, там стоит платформа 8.1.11.67 - все равно те же яйца.

up

была такая хрень, лечилась обновлением платформы. в  вашем случае могу порекомендовать установить обновление, даже если оно уже установлено :)

можно попробовать выгрузить и загрузить в последнюю 8.2 в режиме совместимости, если вылечится - юзать 8.2 в режиме совместимости...

(28) я писал, что пробовал на разных компах с локально установленной платформой разных версий, и самой последней и не очень.
(29) попробовал, при преобразовании структуры данных также вылетает.

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

(31) Ничего, повторение - мать учения.

+(32) за неделю, месяц, год :)

(17)
700 документов? Полдня работы средней организации. )))

Прежде чем менять конфигурацию (не динамически),надо делать архив. Это аксиома. А бэкапы настраивать почаще, чем раз в день, если любишь по-живому обновлять

(34) Читай выше внимательней, я ж написал, организация только неделю как работает в программе. Так что учитывая это обстоятельство, считаю, что уже неплохо поработали сотрудники.
(35) Согласен с тобой полностью. Но это ты уже говоришь про идеал. работу. В реальных ситуациях сложно следовать таким правилам: когда и база здоровая уже, и какой-нибудь начальник слезно просит внести очень важное для него изменение.

(35) Вот если бы не было и на прошлый день архива, вот это уже непрофессионализм/лень. Подчеркни нужное.

up

жалко что база файловая, иначе можно было бы поочереди заменять таблицы из бэкапа чтобы локализовать проблему
а потом в проблемной таблице искать проблемную строку
а потом сравнивать проблемную строку с рабочей...