1С 7.7: тест базы вызывает ее "порчу", последствия... Нужны комментарии
Во время командировки на подшефное предприятие (входит в наш холдинг, городок довольно далеко от столицы, место действия - Украина) местные попросили помочь с переносом БД 1С 7.7 на другой сервер.
1С 7.7 оперативный учет + бухгалтерия, БД в DBF, 1.7 гига, инфа с 2004 г., конфигурация нетиповая (!), целиком самописная, писанная местными "светилами" и обслуживаемая ими же.
Конфигурация ведет бухучет и зп (частично, компоненты расчета не было).
Причина переноса - выход из строя старого сервера. Он представлял собой обычный старый ПК, на плате вздулись конденсаторы, перенос был объяснен так: "...в процессе каждодневной переиндексации (!) БД 1С зависает...".
За неделю до нашего приезда силами местного ИТ отдела (не знакомого с 1С вообще) на другом сервере была запущена 1С в портейбл версии и перенесена сама база (путем копирования ее каталога), однако бухов не устраивало то, что в этом варианте не проходит авторизация пользователей (при запуске не требует пароль).
Нами была установлена комплексная 1С с 25-ми бинарниками, при запуске потребовалась переиндексация в монопольном режиме. После успешного запуска на всякий случай было предложено провести тест БД (режим "Тестирование").
Все выполнялось в присутствии главного бухгалтера.
Тест затянулся на несколько часов, в процессе теста было выявлено несколько ошибок усечения текстового реквизита документов ПН (неопасные, комментарии), неразрешенная ссылка в двух документах на несуществующий справочник (судя по названию "Ситуации" - вспомогательный), изменение времени нескольких ПН документов, а также весьма множественные ошибки отстутствия связей с несколькими типами документов ЗП за довольно старый период. Последнее было на месте объяснено гл. бухом как "... нам тогда-то урезали базу за два года (2004-2005), больше ошибок в ходе тестирования выяслено не было. По результатам на всякий случай весь вывод тестирования был сброшен в текстовый файл для спецов местного франчайзи, писавшего конфу.
Через день после событий бухгалтерия обнаружила значительные расхождения по сальдо счетов и управленческому учету. Ближайшая резервная копия была недельной давности.
Местный франч по данному факту только развели руками и сказали что-то невразумительное в духе "вроде как не должно было такое быть, но все бывает...", они предложили не исправлять текущую БД, а откатиться на копию из бэкапа, чтоби было сделано.
В результате недельная работа отдела бухгалтерии пошла на смарку, вся вина за случившееся была возложена на нас.
В ходе пробного эксперимента появление подобной проблемы ("порча" данной БД в результате тестирования НЕ исправления) подтвердилась.
Подозреваем, что проблема вызвана некорректным усечением франчем БД в далеком прошлом (прямое удаление документов за период без компенсации их движения в счетах и регистрах). Т.к. в рез-те теста проходит пересчет итогов, то это и могло сыграть решающую роль в появлении проблемы.
Себя корим лишь за то, что понадеялись на 1С-овский тест БД в режиме чтения и за то, что не сделали копию БД перед тестированием (по привычке думали, что на подшефном предприятии делают копии автоматом каждый день).
Хотя с другой стороны, как же они будут при таком раскладе дальше жить с такой "странной" БД и верить ее результатам...
Просим прощения за долгое описание проблемы и просим прокомментировать вышесказанное...
1С 7.7 оперативный учет + бухгалтерия, БД в DBF, 1.7 гига, инфа с 2004 г., конфигурация нетиповая (!), целиком самописная, писанная местными "светилами" и обслуживаемая ими же.
Конфигурация ведет бухучет и зп (частично, компоненты расчета не было).
Причина переноса - выход из строя старого сервера. Он представлял собой обычный старый ПК, на плате вздулись конденсаторы, перенос был объяснен так: "...в процессе каждодневной переиндексации (!) БД 1С зависает...".
За неделю до нашего приезда силами местного ИТ отдела (не знакомого с 1С вообще) на другом сервере была запущена 1С в портейбл версии и перенесена сама база (путем копирования ее каталога), однако бухов не устраивало то, что в этом варианте не проходит авторизация пользователей (при запуске не требует пароль).
Нами была установлена комплексная 1С с 25-ми бинарниками, при запуске потребовалась переиндексация в монопольном режиме. После успешного запуска на всякий случай было предложено провести тест БД (режим "Тестирование").
Все выполнялось в присутствии главного бухгалтера.
Тест затянулся на несколько часов, в процессе теста было выявлено несколько ошибок усечения текстового реквизита документов ПН (неопасные, комментарии), неразрешенная ссылка в двух документах на несуществующий справочник (судя по названию "Ситуации" - вспомогательный), изменение времени нескольких ПН документов, а также весьма множественные ошибки отстутствия связей с несколькими типами документов ЗП за довольно старый период. Последнее было на месте объяснено гл. бухом как "... нам тогда-то урезали базу за два года (2004-2005), больше ошибок в ходе тестирования выяслено не было. По результатам на всякий случай весь вывод тестирования был сброшен в текстовый файл для спецов местного франчайзи, писавшего конфу.
Через день после событий бухгалтерия обнаружила значительные расхождения по сальдо счетов и управленческому учету. Ближайшая резервная копия была недельной давности.
Местный франч по данному факту только развели руками и сказали что-то невразумительное в духе "вроде как не должно было такое быть, но все бывает...", они предложили не исправлять текущую БД, а откатиться на копию из бэкапа, чтоби было сделано.
В результате недельная работа отдела бухгалтерии пошла на смарку, вся вина за случившееся была возложена на нас.
В ходе пробного эксперимента появление подобной проблемы ("порча" данной БД в результате тестирования НЕ исправления) подтвердилась.
Подозреваем, что проблема вызвана некорректным усечением франчем БД в далеком прошлом (прямое удаление документов за период без компенсации их движения в счетах и регистрах). Т.к. в рез-те теста проходит пересчет итогов, то это и могло сыграть решающую роль в появлении проблемы.
Себя корим лишь за то, что понадеялись на 1С-овский тест БД в режиме чтения и за то, что не сделали копию БД перед тестированием (по привычке думали, что на подшефном предприятии делают копии автоматом каждый день).
Хотя с другой стороны, как же они будут при таком раскладе дальше жить с такой "странной" БД и верить ее результатам...
Просим прощения за долгое описание проблемы и просим прокомментировать вышесказанное...
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Allan Stark пишет:
Через день после событий бухгалтерия обнаружила значительные расхождения по сальдо счетов и управленческому учету. Ближайшая резервная копия была недельной давности.
Через день после событий бухгалтерия обнаружила значительные расхождения по сальдо счетов и управленческому учету. Ближайшая резервная копия была недельной давности.
Перед переносом на другой сервер и ТиИ не сделали копию?
ТИИ не выполнялся ! ТОЛЬКО "Тестирование". При свидетелях...
Само копирование выполнялось за неделю до событий силами местного ИТ отдела.
Перед тестированием копию не делали. Почему - см. выше.
Мы лишь "по-человечески" установили на данном сервере 1С и провели тест БД...
Откатываться пришлось по сути на новую копию со сторого сервера - недельной давности.
Само копирование выполнялось за неделю до событий силами местного ИТ отдела.
Перед тестированием копию не делали. Почему - см. выше.
Мы лишь "по-человечески" установили на данном сервере 1С и провели тест БД...
Откатываться пришлось по сути на новую копию со сторого сервера - недельной давности.
А, собственно говоря, что требуется то? Комментарии на тему, "как мы переносили базу" и кто виноват (мы или местные бяки)?
Если - "кто виноват", то это и вы и бяки, бекап перед любыми такими действиями это святое. И вы обязательно должны были убедиться в его наличии.
Если - "кто виноват", то это и вы и бяки, бекап перед любыми такими действиями это святое. И вы обязательно должны были убедиться в его наличии.
Копия осталась + несколько копий за более поздний срок.
Да в принципе уже разобрались, доказано...
Они просто по ходу грохнули документы обработкой (2004-2005) и видать с тех пор базу на тест никто не ставил... Хотя с их стороны тоже добиться кого-то виноватого трудно - прошло уже несколько лет.
Да в принципе уже разобрались, доказано...
Они просто по ходу грохнули документы обработкой (2004-2005) и видать с тех пор базу на тест никто не ставил... Хотя с их стороны тоже добиться кого-то виноватого трудно - прошло уже несколько лет.
А Ваши функциональные обязанности связаны с оказанием такой помощи?
Теоретически - связаны, т.к. в головном офисе администрирование многочисленных баз 1С - одна из прямых обязанностей, к тому же по правилам нашей компании отделы головного офиса курируют такие же отделы во всех отдаленных офисах и фирмах, входящих в холдинг.
В должностной естественно конкретно такой случай естественно не описан, там стандартные общие фразы каасательно обязаннстей в компании в целом.
Я понимаю, бывают ситауции - приехали по одному делу, а тут у людей проблема.
Как раз такой случай, помогли на свою голову...
(15)
Значит, это бред :-)
по сабжу - извините, но виноваты только Вы. Не сделали копию, не сделали элементарную проверку.
Например, ОСВ до и после Ваших действий.
Lena Torpeda пишет:
Ребята,вы не в чем не виноваты. Виноваты те, кто не зная вас, попросил помочь.
Ребята,вы не в чем не виноваты. Виноваты те, кто не зная вас, попросил помочь.
Значит, это бред :-)
по сабжу - извините, но виноваты только Вы. Не сделали копию, не сделали элементарную проверку.
Например, ОСВ до и после Ваших действий.
Еще раз внесу ясность.
Все работы велись по просьбе местного отдела ИТ и бухгалтерии.
По базе после полноценной инсталляции 1С на в качестве подстраховки было проведено лишь тестирование (НЕ ТИИ), по результатам которого было принято решение продолжать в ней работу (бухи торопили).
Тестирование выявило в прошлом некорректное усечение БД со стороны франчайзи.
Также процесс тестирования "испортил" БД (полагаю, за счет пересчета итогов, которое 1С 7.7 выполняет и в режиме чистого тестирования).
Все.
Все работы велись по просьбе местного отдела ИТ и бухгалтерии.
По базе после полноценной инсталляции 1С на в качестве подстраховки было проведено лишь тестирование (НЕ ТИИ), по результатам которого было принято решение продолжать в ней работу (бухи торопили).
Тестирование выявило в прошлом некорректное усечение БД со стороны франчайзи.
Также процесс тестирования "испортил" БД (полагаю, за счет пересчета итогов, которое 1С 7.7 выполняет и в режиме чистого тестирования).
Все.
Если это связано с Вашими обязанностями - Вы виноваты, что не сделали копию и сразу не проверили.
Если не связано - виноваты что взялись.
Цель этой темы? Снять ответственность с себя и показать начальству?
Или рассказать о "странном" поведении ТиИ в режиме тестирования?
Или франчей поругать?
Если не связано - виноваты что взялись.
Цель этой темы? Снять ответственность с себя и показать начальству?
Или рассказать о "странном" поведении ТиИ в режиме тестирования?
Или франчей поругать?
Например, ОСВ до и после Ваших действий.
Конфигурация НЕ типовая, там сам черт ногу сломит. Конфа походу "втыкивалась" на все случаи жизни - там и для бухии, и для зп (причем без компоненты Рассчет), и для учебных заведений, и для кафе, и для много чего другого документы, отчеты и прочая есть... А сейчас работает а производствнном предприятии :-D
ОСВ делали бухи уже без меня. Обнаружили на след. день, меня уже не было (уехал обратно в столицу).
Цель этой темы?
1. Выговориться...
Начальству по-барабану. Бухи сказали, что виноваты мы.
2. Подтвердить (желательно на собственном опыте), что в ТИИ в режиме тестирования некорректная БД может быть испорчена.
Оффдок. 1С кстати вроде как утверждает что в режиме Тестирования БД открывается только на чтение...
Allan Stark пишет:
Конфигурация НЕ типовая
Конфигурация НЕ типовая
Ну и что? Как это влияет на необходимость создания резервной копии? Или хотя бы убедиться, что есть сегодняшняя?
А спросить, когда последний раз ТиИ делали? Или самим в Журнале регистрации посмотреть?
Allan Stark пишет:
и для зп (причем без компоненты Рассчет)
и для зп (причем без компоненты Рассчет)
Ну и что?
Allan Stark пишет:
ОСВ делали бухи уже без меня
ОСВ делали бухи уже без меня
Самому надо было
У меня был случай уникалный и единственный, местный сисадмин перенес базу с одного компа на другой и остатки в отчетах поехали, после долгой и нудной процедуры кто что делал, выяснилось:
сисадмин не установил на другой комп платформу, а просто скопировал папку 1cv77 с бином и всеми папками баз. После нормальной установки платформы и переноса баз еще раз, все встало на свои места.
сисадмин не установил на другой комп платформу, а просто скопировал папку 1cv77 с бином и всеми папками баз. После нормальной установки платформы и переноса баз еще раз, все встало на свои места.
Allan Stark а с чего вы взяли что база была нормальной до Вашей работы?
Доказать это уже невозможно. Есть вариант, что Вас просто подставили, ведь неизвестно кого они еще "привлекали" так же как и Вас. Действительно есть вина в том что Вы не выполнили все необходимые действия, в следующий раз умнее будете.
Доказать это уже невозможно. Есть вариант, что Вас просто подставили, ведь неизвестно кого они еще "привлекали" так же как и Вас. Действительно есть вина в том что Вы не выполнили все необходимые действия, в следующий раз умнее будете.
Все же по поводу Вопроса № 2.
ПОЧЕМУ "Тестирование" таки может испортить "неправильную" БД, если в оффдоках 1С пишут, что в этом режиме происходит только ТЕСТ БД и она открывается ТОЛЬКО в режиме чтения ?
Или это таки особенность 1С 7.7 ?
ПОЧЕМУ "Тестирование" таки может испортить "неправильную" БД, если в оффдоках 1С пишут, что в этом режиме происходит только ТЕСТ БД и она открывается ТОЛЬКО в режиме чтения ?
Или это таки особенность 1С 7.7 ?
(32)
А можно ссылку?
Но встроенный хелп, дествительно, пишет
Если предполагается провести только тестирование информационной базы, то выбирается опция Только тестирование, если же требуется еще и исправление ИБ, то отмечается опция Тестирование и исправление.
Я думаю, да :-)
Кстати, обратите внимание, что при выборе режима "Только тестирование" становится недоступной галочка "Упаковка таблиц информациооной базы" и кнопка "Настройка"
Возможно, в этом режиме просто не выполняются действия по обработке несуществующих ссылок и при частичной потере данных. И упаковка таблиц
Allan Stark пишет:
если в оффдоках 1С пишут, что в этом режиме происходит только ТЕСТ БД и она открывается ТОЛЬКО в режиме чтения
если в оффдоках 1С пишут, что в этом режиме происходит только ТЕСТ БД и она открывается ТОЛЬКО в режиме чтения
А можно ссылку?
Но встроенный хелп, дествительно, пишет
Если предполагается провести только тестирование информационной базы, то выбирается опция Только тестирование, если же требуется еще и исправление ИБ, то отмечается опция Тестирование и исправление.
Allan Stark пишет:
Или это таки особенность 1С 7.7 ?
Или это таки особенность 1С 7.7 ?
Я думаю, да :-)
Кстати, обратите внимание, что при выборе режима "Только тестирование" становится недоступной галочка "Упаковка таблиц информациооной базы" и кнопка "Настройка"
Возможно, в этом режиме просто не выполняются действия по обработке несуществующих ссылок и при частичной потере данных. И упаковка таблиц
Allan Stark по второму вопросу.
Думаю проблема была изначально в битых индексных файлах. Индексирование не проходило на старом сервере возможно из-за битых дисков... Причину придумайте сами...
После индексирования база стала окончательно "кривой" с точки зрения бухгалтеров, т.к. изменился финансовый результат. Это не значит, что прежний результат был "правильным". Просто эти данные были переданы в налоговую, руководству, и т.д., и т.п.
Скорее всего база была повреждена и были повреждены индексы.
Переиндексация привела к изменению финансового результата.
Тестирование ничего не изменило в базе.
Думаю проблема была изначально в битых индексных файлах. Индексирование не проходило на старом сервере возможно из-за битых дисков... Причину придумайте сами...
После индексирования база стала окончательно "кривой" с точки зрения бухгалтеров, т.к. изменился финансовый результат. Это не значит, что прежний результат был "правильным". Просто эти данные были переданы в налоговую, руководству, и т.д., и т.п.
Скорее всего база была повреждена и были повреждены индексы.
Переиндексация привела к изменению финансового результата.
Тестирование ничего не изменило в базе.
(34)
Да...
ОСВ перед тестированием я не прогонял, да и не мог собственно этого сделать, я же не в курсе какие результаты считать правильными, а какие нет.
Факт многочисленных неуспешных попыток переиндексации БД на старом сервере налицо (со слов гл. бухгалтера).
Так что весьма вероятно. Спасибо.
Да...
ОСВ перед тестированием я не прогонял, да и не мог собственно этого сделать, я же не в курсе какие результаты считать правильными, а какие нет.
Факт многочисленных неуспешных попыток переиндексации БД на старом сервере налицо (со слов гл. бухгалтера).
Так что весьма вероятно. Спасибо.
(35) Как я понял, тема закрыта?
Но все же позволю дать небольшой совет на будующее
А не надо знать. Просто сохранить их в виде таблицы до. А потом сравнить их с тем, что после.
Но все же позволю дать небольшой совет на будующее
Allan Stark пишет:
я же не в курсе какие результаты считать правильными, а какие нет.
я же не в курсе какие результаты считать правильными, а какие нет.
А не надо знать. Просто сохранить их в виде таблицы до. А потом сравнить их с тем, что после.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот