Подскажите, как разобраться с Error #: -120 // 1Sentry.dbf
17.06.2008
23:28
#1
База на DBF.
Не дает проводить накладные. При проводке пишет:
Error # : -120
writing to file
D:\...\1SENTRY.DBF
и выбрасывает из 1С.
Не дает проводить накладные. При проводке пишет:
Error # : -120
writing to file
D:\...\1SENTRY.DBF
и выбрасывает из 1С.
18.06.2008
08:23
#2
1. Проверьте доступ на папку с базой
2. Можно попробовать сделать тестирование и исправление (но не забудте сначала сделать архивную копию)
3. Если и это не помогло, то возможно у вас проблемы с жестким диском. Попробуйте сделать так:
- В конфигураторе сделайте "Выгрузить данные"
- Скопируйте базу в другое место (лучше даже на другой компьютер) и там уже сделайте "Загрузить данные"
2. Можно попробовать сделать тестирование и исправление (но не забудте сначала сделать архивную копию)
3. Если и это не помогло, то возможно у вас проблемы с жестким диском. Попробуйте сделать так:
- В конфигураторе сделайте "Выгрузить данные"
- Скопируйте базу в другое место (лучше даже на другой компьютер) и там уже сделайте "Загрузить данные"
18.06.2008
10:51
#3
1SENTRY - dbf-ка содержащая проводки.
Сейчас бьюсь над восстановлением базы в которой как раз с этой ошибки всё и началось.
Бух-ия одной конторы давно столкнулась с этой ошибкой, но через раз-два удавалось проводить документ. Когда же ошибка стала критической, то бишь транспорант стал вываливаться при каждой попытке проведения с последующим вылетом из базы, обратились за помощью к нам.
Результат:
Из-за ошибки возникшей в файловой системе где-то месяцев 6 назад происходило постепенное разрешение структуры ряда dbf-ок.
В конечном итоге при попытке тестирования выяснилось что рухнули файлы 1Sentry, 1Soper, 1Saccs
то бишь, содержимое операций, содержимое проводок и план счетов.
Попытка восстановить базу штатными средствами приводила к тому что из за нарушения структуры ссылок система не смогла восстановить связи и просто напросто очищала всю информацию об операциях, перепроведение документов приводило к сообщению о том что "Указанный в проводке счёт не принадлежит указанному плану счетов"
Решение:
Создал пустую базу.
Нашёл неплохую обработочку при помощи которой можно выгрузить документы и связанные с ними записи справочников.
Где нашёл не помню, вроде как с инфостарта ссылочка привела
имя архива perenos_ole_126.zip
Обработка работает через OLE что существенно ускоряет процесс.
Машинка слабоватая конечно, но за 10 часов обработка перенесла мне данные (причём без "неиспользующихся" записей справочников) за 8 лет плодотворной работы (примерный объём 20-25 документов в день)
Если штатные процедуры конфигуратора не помогут, советую воспользоваться данной методикой.
Рекомендую отключить опцию проведения при выгрузке (очень мешает из-за наличия учётных косяков в базе) А после полной загрузки выполнить проведение при помощи групповой обработки документов.
З.Ы. Кстати вот ссылочка, нашёл снова, может кому пригодится
Сейчас бьюсь над восстановлением базы в которой как раз с этой ошибки всё и началось.
Бух-ия одной конторы давно столкнулась с этой ошибкой, но через раз-два удавалось проводить документ. Когда же ошибка стала критической, то бишь транспорант стал вываливаться при каждой попытке проведения с последующим вылетом из базы, обратились за помощью к нам.
Результат:
Из-за ошибки возникшей в файловой системе где-то месяцев 6 назад происходило постепенное разрешение структуры ряда dbf-ок.
В конечном итоге при попытке тестирования выяснилось что рухнули файлы 1Sentry, 1Soper, 1Saccs
то бишь, содержимое операций, содержимое проводок и план счетов.
Попытка восстановить базу штатными средствами приводила к тому что из за нарушения структуры ссылок система не смогла восстановить связи и просто напросто очищала всю информацию об операциях, перепроведение документов приводило к сообщению о том что "Указанный в проводке счёт не принадлежит указанному плану счетов"
Решение:
Создал пустую базу.
Нашёл неплохую обработочку при помощи которой можно выгрузить документы и связанные с ними записи справочников.
Где нашёл не помню, вроде как с инфостарта ссылочка привела
имя архива perenos_ole_126.zip
Обработка работает через OLE что существенно ускоряет процесс.
Машинка слабоватая конечно, но за 10 часов обработка перенесла мне данные (причём без "неиспользующихся" записей справочников) за 8 лет плодотворной работы (примерный объём 20-25 документов в день)
Если штатные процедуры конфигуратора не помогут, советую воспользоваться данной методикой.
Рекомендую отключить опцию проведения при выгрузке (очень мешает из-за наличия учётных косяков в базе) А после полной загрузки выполнить проведение при помощи групповой обработки документов.
З.Ы. Кстати вот ссылочка, нашёл снова, может кому пригодится
Читают тему
(гостей: 1)