1с 7 ошибка 120
Клиенту потребовался срочный перенос ИБ 1С 7.7 с файлового режима на клиент-серверный (SQL).
Они уперлись в пределы количества возможных записей в таблицах и объем базы, которая уже достигла размера в 8,57 Гб.
Начали подготовку. При экспорте данных в zip-файл (стандартная операция « Администрирование — Выгрузить данные. ») получили эту ошибку.
Особенности
- ограничение связано с внутренним zip-архиватором;
- для работы архиватора требуется, чтобы на диске, где создается временный файл, свободного места необходимо в 2 раза больше, чем размер получающегося zip-архива;
- создаваемый zip-архив после ошибки получается поврежденным;
- ошибка может возникнуть не только при выгрузке, но и загрузке данных.
Причина — некорректная работа приложения 1С с большими базами. Проблема связана с ограничением архиватора на размер ИБ при упаковке данных.
При поиске по Интернету в одном источнике сообщалось, что если создаваемый 1Cv77.dat менее 4 Гб, и 1cv7.zip менее 2 Гб, то проблем быть не должно.
Забегая вперед, скажем — в нашем случае размер dat-файла получился 2138 Мб, но все равно столкнулись с этим ограничением.
Что делать
Единственная рекомендация — оставлять только текущий год или другой период, производить упаковку файлов базы из Конфигуратора.
Альтернативные варианты
Можно воспользоваться плагином для 1С:Предприятие 7.7 — Unload_Dat_Fix.rar (автор romix — см. описание внешних компонентов 1С:Предприятие на сайте в разделе «Плагины»). Процесс установки и удаления плагина описаны в папке Patch дистрибутива.
Исправляет ошибку 1С:Предприятие при штатной выгрузке и загрузке больших информационных баз (несколько гигабайт)
Более новая версия, не задает вопросов при выгрузке.
Порядок применения
- После установки плагина, при выгрузке данных на экране появится окно с запросом: « Отключить архивирование файла dat? ». При архивировании больших баз ответьте «Да». В этом случае zip-архив будет записан пустой dat-файл, а необходимые данные будут сохранены в каталоге ИБ под именем romix.dat.
- В случае ответа «Нет», 1С поведет себя штатно — поместит dat-файл в архив выгрузки. При загрузке данных, плагин запросит размещение файла dat. Если файл находится внутри zip-архива, вы можете нажать Esc и отказаться от выбора размещения.
По описанию — все понятно, но у нас не сработала эта версия. Она оказалась актуальной для ОС младше Windows 7/Server 2008. Выручил другой ресурс — AVProg с обновленной (доработанной) версией плагина .
Причина? В связи с изменением состава DLL в Windows 7 оригинальный плагин перестал работать. Данный плагин — это простое портирование оригинального плагина под Windows 7/Server 2008 R2.
Делает абсолютно то же самое, что и основной плагин — при выгрузке данных 1С:Предприятие позволяет не упаковывать в zip-архив файл 1Cv77.dat который 1С упаковать и не может (больше 2 ГБ), но пытается.
Решение проблемы: Как уменьшить размер файла 1SBKTTL.DBF?
АДМИНИСТРИРОВАНИЕ 1С 8 → перейти в меню [СТАТЬИ И ИНСТРУКЦИИ]
Ошибки появляются при проведении документов или пересчёте бухгалтерских итогов. Программа пытается произвести запись в файл dbf, а особенно сти файловой системы не позволяют ей это сделать. Если размер файла "подкрадывается" к двум гигабайтам - рекомендуется произвести "свёртку" базы данных с помощью обработки WRAP.ert. При выполнении это процедуры - остатки свернуться на начало отчётного периода (желательно на начало года). Предварительно обязательно сделайте архивную копию, так как эта процедура не обратимая. Если базу "резать" по каким-то причинам нельзя, то можно воспользоваться сторонним решением " Kernel3x". Применение этой компоненты решает эту проблему, однако используете Вы её на свой страх и риск!
Для профилактики и уменьшения размера файла 1SBKTTL.DBF, рекомендую периодически выполнять следующие операции:
1) Выгрузка - загрузка информационной базы данных1С. Запускаем 1С в режиме "Конфигуратор". Не забываем выделить нужную базу в списке. Заходим в Меню -> Администрирование -> Выгрузка данных. Выбираем путь к файлу, в который будет выгружена база. Нажимаем "ОК". Ждём.
2) После выгрузки-загрузки информационной базы - рекомендую выполнить полное тестирование и исправление. Запускаем 1С в режиме "Конфигуратор". Не забываем выделить нужную базу в списке. Заходим в Меню -> Администрирование -> Тестирование и исправление. Устанавливаем все признаки. Птичку ставим на "Тестирование и исправление". Нажимаем "Выполнить". Процедура длительная - ждём.
После выполнения всех операций заходим в каталог нашей базы данных и смотрим на размер файла 1SBKTTL.DBF. В нашем примере, он уменьшился более чем в два раза. Это позволит нам вести учёт еще некоторое время без принятия дополнительных мер. На скриншоте видно, что уменьшился не только 1SBKTTL.DBF, но и другие файлы DBF ( 1SENTRY.DBF, 1SACCSEL.DBF, DT50647.DBF, 1SCONST.DBF и прочие ).
Помните, что профилактические меры в любой среде обходятся намного экономичние и занимают меньше временных и материальных затрат, чем последующее исправление и восстановление. База данных 1С это постоянно растущий механизм, за которым нужно наблюдать, исправлять ошибки, производить регламентные задания. Если Вам нужен специалист по 1С, который выполнит эти и любые другие работы, можете обратиться через контактную форму.
Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal
Проблема усугублялась ещё и тем что в этой базе было более 300 тысяч единиц номенклатуры и несколько десятков тысяч документов за два с половиной года. В общем база данных приличного размера.
Так как у меня под рукой был настроеный сервер с MS SQL, то самым простым способом мне показалось "выгрузить данные", загрузить их в SQL, а уже там свернуть той самой стандартной wrap.ert. Более того, я уже так делал пару раз.
Но с SQL-базой не вышло. При загрузке номенклатуры, примерно на 270800-й позиции, выдавалась "ошибка загрузки данных" без объяснения подробностей. А разобраться, какой же там непечатный символ (или ещё что-нибудь) в 840-мегабайтном файле выгрузки не хочет "съесть" SQL, просто не реально.
Точно так же (по непонятным причинам), не сработал и метод с использованием kernel33.dll — файлы отказались расти больше двух гигабайт.
Пришлось решать задачу альтернативными методами.
Для начала нужно было сделать так чтобы 1С ничего не писала в файл с итогами при свёртке базы. Ведь данные об итогах добавляются при записи новых "операций вручную" с остатками. Пришлось доработать wrap.ert, заменив "операции" на непроведённые "бухгалтерские справки". Файл итогов перестал увеличиваться и все документы по вводу остатков сформировались.
Но это ещё не всё! Обработка свёртки начала удалять старые документы и тут внезапно появилась знакомая ошибка записи в 1SBKTTL.DBF. При удалении или распроведении документов в файл бухгалтерских итогов 1С всё равно что-то пишется. Оказалось для того чтобы этого не происходило, нужно "установить расчёт" (управление бухгалтерскими итогами) куда-нибудь назад, чтобы удаляемые документы были позже по дате проведения.
Помечать на удаление несколько десятков тысяч документов пришлось самописной обработкой. Ну а дальше уже всё легко: пометка на удаление всей номенклатуры, удаление помеченых объектов, снятие пометки удаления с оставшейся номенклатуры, проведение бухгалтерских справок с проводками ввода остатков, полный пересчёт итогов и упаковка таблиц базы данных.
На весь этот "путь к успеху", в моём случае, было потрачено несколько суток, но это в основном из-за большого количества номенклатуры и из-за метода "научного тыка".
Возникает подобная ошибка при попытке проведения результатов ревизии. После появления первой ошибки появляется в окне и вторая:
Reading File
E:\1C\BD\DT3114.DBF
Ошибка 2 : Невосстановимая ошибка Базы Данных. Код: -10000. Нераспознанная ошибка.
Система: 1С: Предприятие 7.7. А конфигурация не столь важна.
Решение проблемы : Что можно сказать в этом случае? Почти наверняка произошло совсем недавно (или давно, просто к таблице базы данных не было обращения, а потому можно было и дальше работать) отключение электроэнергии. Или просто выключили компьютер. Или резко завершили процесс 1С 7.7. В общем, не дали нормально доделать какие-то операции 1С. Как вариант - может быть повреждён уже непосредственно жёсткий диск.
Что нужно делать? Нужно произвести полную проверку таблиц базы данных.
1. Скопировать базу данных (обязательно)
2. Зайти в БД 1С в Конфигураторе. Там "Администрирование --> Тестирование и исправление". Выбрать все галочки, а также отметить "тестирование и исправление" (проверить, что выполнен пункт 1). Может статься так, что система не пустит это делать, потому что кто-то ещё сидит в базе данных. Проверить, кого именно нужно выгнать, следует через Монитор пользователей. В крайнем случае (произошёл глюк) произведите перезагрузку компьютера, где хранятся файлы.
3. Если после проведения тестирования (а оно может длиться и несколько часов) ошибка остаётся, то можно попробовать произвести жёсткую переиндексацию. Это можно сделать и без использования п2. Часто она помогает. Нужно зайти в каталог БД 1С (проверив, что выполнен п1). Найти и удалить все файлы с разрешением *.cdx. Лучше всего воспользоваться файловым менеджером при этом (в стиле Total Commander). Затем зайти в оболочку 1С монопольно.
4. Если не помогло, то попробовать пару раз п2. Если всё равно не получается, а ошибки остаются, то тогда стоит произвести в Конфигураторе выгрузку данных (Администрирование --> Выгрузка данных). Лучше всего (для исключения поломок HDD) скопировать базу данных на другой компьютер и делать это уже там. После чего создать базу данных новую и также загрузить все данные. Использование этого варианта говорит о том, что всё-таки некоторое (большее или меньшее количество) данных будет потеряно.
Читайте также: