Бухучет 77.Сбой БД
10.10.2013
09:34
#1
на ПК установлено три конфигурации версии 77(BIN 27): бухучет , зарплата и кадры, предприниматель.
Зарплата и кадры, предприниматель работают нормально, а при загрузке бухучета появляется заствка "Проверка легальности получения обновлений"(см.Doc1), подтверждаешь легальность получения обновлений выдается ошибка(Doc2) .
Рабочая база релиз 561, обновляли 08.07.13 работали нормально и вдруг появляется эта заствка, базу протестировали , ошибок нет, обновили на 564 релиз, обновление конфигурации прошлао нормально, в плане счетов расхождений нет, ошибка таже.
И это происходит со всеми базами бухучета:
1.есть архивная БД 519 релиз, загружаешь ее , получаешь заставку на легальность, ошибку.
2.Восстановили копию рабочей БД, запустили все нормально, обновили на 564 релиз, запустили, заставка на легальность и ошибка (Doc2).
Антивирус Касперский, автоматически обновляется, если вирус, то какой-то уж очень разборчивый , именно бухучет, зарплата и предприниматель ему не нужны...
P.S.На другом ПК Восстановили копию рабочей БД, запустили все нормально, обновили на 564 релиз, запустили, заставку на легальность подтвердилии , ошибок нет.
Зарплата и кадры, предприниматель работают нормально, а при загрузке бухучета появляется заствка "Проверка легальности получения обновлений"(см.Doc1), подтверждаешь легальность получения обновлений выдается ошибка(Doc2) .
Рабочая база релиз 561, обновляли 08.07.13 работали нормально и вдруг появляется эта заствка, базу протестировали , ошибок нет, обновили на 564 релиз, обновление конфигурации прошлао нормально, в плане счетов расхождений нет, ошибка таже.
И это происходит со всеми базами бухучета:
1.есть архивная БД 519 релиз, загружаешь ее , получаешь заставку на легальность, ошибку.
2.Восстановили копию рабочей БД, запустили все нормально, обновили на 564 релиз, запустили, заставка на легальность и ошибка (Doc2).
Антивирус Касперский, автоматически обновляется, если вирус, то какой-то уж очень разборчивый , именно бухучет, зарплата и предприниматель ему не нужны...
P.S.На другом ПК Восстановили копию рабочей БД, запустили все нормально, обновили на 564 релиз, запустили, заставку на легальность подтвердилии , ошибок нет.
10.10.2013
16:06
#4
Легальность тут не причем.
Ошибка возникает в месте алгоритма, который у вас отрабатывать не должен, а именно, при переходе конфигурации на релиз 7.70.421 (самый первый релиз этой редакции давно ушедший в лета).
У вас номер текущего релиза некорректно определяется. Нужно сделать Тестирование и обновление базы данных перед обновлением (не забудьте сохраниться).
Грустный пример, который, возможно, отражает и вашу ситуацию:
- Работа с базой была завершена аварийно.
- От переиндексации таблиц при входе отказались.
- Индекс таблицы констант (1SCONST.CDX) оказался битым.
- По битому индексу система не сумела в таблице констант (1SCONST.DBF) найти запись с номером текущего релиза.
- Поэтому решила, что это первый запуск и потащила конфигурацию через все процедуры автозаполнения базы стартовыми значениями.
- Вписала в таблицу констант номер релиза второй раз и в таблице оказалось две таких записи, хотя должна быть одна уникальная.
- Итого получилась каша, при которой любая переиндексация базы позиционировала индексом на неверную запись о номере релиза и каждый раз система запускала процедуры обновления.
- Вся эта помойка полечилась ручной правкой таблицы 1SCONST.DBF с удалением некорректной записи сведений о номере релиза.
Ошибка возникает в месте алгоритма, который у вас отрабатывать не должен, а именно, при переходе конфигурации на релиз 7.70.421 (самый первый релиз этой редакции давно ушедший в лета).
У вас номер текущего релиза некорректно определяется. Нужно сделать Тестирование и обновление базы данных перед обновлением (не забудьте сохраниться).
Грустный пример, который, возможно, отражает и вашу ситуацию:
- Работа с базой была завершена аварийно.
- От переиндексации таблиц при входе отказались.
- Индекс таблицы констант (1SCONST.CDX) оказался битым.
- По битому индексу система не сумела в таблице констант (1SCONST.DBF) найти запись с номером текущего релиза.
- Поэтому решила, что это первый запуск и потащила конфигурацию через все процедуры автозаполнения базы стартовыми значениями.
- Вписала в таблицу констант номер релиза второй раз и в таблице оказалось две таких записи, хотя должна быть одна уникальная.
- Итого получилась каша, при которой любая переиндексация базы позиционировала индексом на неверную запись о номере релиза и каждый раз система запускала процедуры обновления.
- Вся эта помойка полечилась ручной правкой таблицы 1SCONST.DBF с удалением некорректной записи сведений о номере релиза.
10.10.2013
17:10
#5
Надо переварить, но на другом ПК востановленная копия не дает ошибки, а на старом востановленная копия также дает ошибку?
11.10.2013
00:22
#6
Спасибо Thorvardr! Ваш "грустный пример" достоверно описал нашу ситуацию:
удалили в 1SCONST.DBF запись о 7.70.420 релизе , проблема исчезла.
Вот только не понятно обо что бьется 1SCONST.DBF на этом компьютере,
я уже писала что запустили базу 5-6-ти летней давности(519 релиз) ошибка,
востановили копию текущей базы 561 релиз,запустили все нормально ,
протестировали, обновили, запустили - ошибка. Для всех баз один и тот же сбой.
На другом компе восстановили копию, обновили все нормально работает.
удалили в 1SCONST.DBF запись о 7.70.420 релизе , проблема исчезла.
Вот только не понятно обо что бьется 1SCONST.DBF на этом компьютере,
я уже писала что запустили базу 5-6-ти летней давности(519 релиз) ошибка,
востановили копию текущей базы 561 релиз,запустили все нормально ,
протестировали, обновили, запустили - ошибка. Для всех баз один и тот же сбой.
На другом компе восстановили копию, обновили все нормально работает.
11.10.2013
12:13
#7
Вот и Володя наш из отпуска вернулся, и Александра что-то не тормошит с фотоотчетом.
Читают тему
(гостей: 1)