El_Duke
06.09.10
✎
08:51
1С 7.7, бухгалтерская база, платформа 25, релиз 518, база дбф.
При попытке войти в режиме предприятия вылетает ошибка:
Error # 70
Codebase error reding file 1SBKTTL.dbf
Ошибка доступа к таблице 1SBKTTL
Попытка сделать ТИИ вылетает с сообщением о неисправимой ошибке.
Есть бэкап недельной давности и от релиза 517.Тупо заменить файл 1SBKTTL.dbf в данном случае как я понимаю нельзя.
Господа, посоветуйте что можно сделать ???
PuhUfa
06.09.10
✎
08:56
удалить его совсем и зайти монопольно
Umka2008
06.09.10
✎
08:57
1 — ес-но на копии, а то щас нафигачит
PuhUfa
06.09.10
✎
08:57
+(1) вместе с ним еще 1SBKTTL удалить
skunk
06.09.10
✎
08:58
прибить … рассчитать итоги
El_Duke
06.09.10
✎
15:29
Нашелся пятничный бэкап базы который спас.За предложенные способы спасибо, учту в дальнейшем
Эльниньо
06.09.10
✎
16:31
(5) Хм. Итоги палюбасу пересчитай. А надёжнее сделать (3) и (4).
1Сергей
06.09.10
✎
16:54
Советам уже не поможешь
Эльниньо
06.09.10
✎
17:00
(7) Это почему?
mm1ck
06.09.10
✎
21:53
И после всех танцев с бубном ТиИ сделать не мешает.
ilkoder
06.09.10
✎
21:59
Есть какой-то досовский редактор dbf файлов со встроенной лечилкой, раньше часто помогал — так в них какие-то ошибки бывают…
Nikitos
06.09.10
✎
22:26
у меня было так: бух делал какую-то операцию (не помню уже что), но ее предупреждало, что это «невосстановимая» операция. Бух прервал это дело…
Руками восстанавливал пару dbfок, т.к. архива не было 
В двух таблицах появились непонятные лишние поля…
vitecd
07.09.10
✎
03:09
раньше это лечилось «сауроном», только я его потерял и найти не могу 
раньше на «чипадейле» лежал, дак «чипадейла» вроде как нету больше…
Сервак на вин 2000 сервер, базы 1С файловый вариант: бах седня ошибки в 5 из 6 бухгалтерских базах, ЗиК нормально все базы. Во каждой базе по одной неисправимой ошибке на один файл (1SENTRY, 1SSBSEL, 1SOPER, 1SBKTTL). ТиС не помогает, выгрузка не производиться, диск на ошибки проверил не помогло. Все битые файлы не читаются просмотрщиком ошибка чтения заголовка ну и размер у них 0. Вообщем я так понимаю их не вылечить. Архив есть 2-х дневной давности, как правильно файлы эти восстановить без восстановления всего архива.
на копии базы просто кинь эти файлы из архива и перепроведи последнии 2 дня
Видимо какой то ловкач решил принести из дому архив базы, на которой он поработал дома в воскресенье под другой операционкой — такое частенько происходит на 25 платформе или на 27 без сопряжения между ОС
Найди ловкача(ловкачиху) дай прикурить и потом заставь отдать архивы из дому тебе, а сам с ними разберись
Так он побореться с последствиями не устранив причину — причина в ловкачихе …
там не кто не таскает так говорят бухи типа кроме их ни кто
+т.е. они вообще этого не умеют делать
некто таскает? прострели некте колено
просто зубы повыбиваю и все
я сам на такое наткнулся когда у меня появился ноут с 64 разрядной виндовс 7, а дома попрежнему хрюша, пару раз запорол так базу — (правда копию конечно же) и тогда понял что почем и как…
Все они так говорят. Конец года. по любому кто-то что-то не успевает. А скопировать фаловую базу на флешку и обратно элементарно. Более-менее продвинутый юзер в в виде сына мужа могг лекгко показать, как сделать.
так то да все возможно как раз на выходные дело было
самое смешное что они могли не только со своими данными принести архив и не только со своей конфой
сделал на одной базе вроде норм вот только ТиИ чет ругается на проводки но это фигня..
Тэги: 1С 7.7 и ранее
Комментарии доступны только авторизированным пользователям
- IT
- Cancel
Столкнулся с неприятной проблемой: в одной из баз «Бухгалтерский учет 4.5», файл с бухгалтерскими итогами достиг 2 гигабайт. Естественно, ни один документ провести не получается и свернуть базу стандартной обработкой wrap.ert — тоже. При любом пересчете бухгалтерских итогов появлялось сообщение об ошибке записи в 1SBKTTL.DBF (Codebase Error #: -120. Writing to file).
Проблема усугублялась ещё и тем что в этой базе было более 300 тысяч единиц номенклатуры и несколько десятков тысяч документов за два с половиной года. В общем база данных приличного размера.
Так как у меня под рукой был настроеный сервер с MS SQL, то самым простым способом мне показалось «выгрузить данные», загрузить их в SQL, а уже там свернуть той самой стандартной wrap.ert. Более того, я уже так делал пару раз.
Но с SQL-базой не вышло. При загрузке номенклатуры, примерно на 270800-й позиции, выдавалась «ошибка загрузки данных» без объяснения подробностей. А разобраться, какой же там непечатный символ (или ещё что-нибудь) в 840-мегабайтном файле выгрузки не хочет «съесть» SQL, просто не реально.
Точно так же (по непонятным причинам), не сработал и метод с использованием kernel33.dll — файлы отказались расти больше двух гигабайт.
Пришлось решать задачу альтернативными методами.
Для начала нужно было сделать так чтобы 1С ничего не писала в файл с итогами при свёртке базы. Ведь данные об итогах добавляются при записи новых «операций вручную» с остатками. Пришлось доработать wrap.ert, заменив «операции» на непроведённые «бухгалтерские справки». Файл итогов перестал увеличиваться и все документы по вводу остатков сформировались.
Но это ещё не всё! Обработка свёртки начала удалять старые документы и тут внезапно появилась знакомая ошибка записи в 1SBKTTL.DBF. При удалении или распроведении документов в файл бухгалтерских итогов 1С всё равно что-то пишется. Оказалось для того чтобы этого не происходило, нужно «установить расчёт» (управление бухгалтерскими итогами) куда-нибудь назад, чтобы удаляемые документы были позже по дате проведения.
Помечать на удаление несколько десятков тысяч документов пришлось самописной обработкой. Ну а дальше уже всё легко: пометка на удаление всей номенклатуры, удаление помеченых объектов, снятие пометки удаления с оставшейся номенклатуры, проведение бухгалтерских справок с проводками ввода остатков, полный пересчёт итогов и упаковка таблиц базы данных.
На весь этот «путь к успеху», в моём случае, было потрачено несколько суток, но это в основном из-за большого количества номенклатуры и из-за метода «научного тыка».
Перейти к контенту
Если база данных 1С Предприятие 7.7 используется в файловом варианте (DBF), а объем регистрируемых данных велик, то рано или поздно её придётся уменьшать. Один из самых быстрорастущих файлов в базе данных — это 1SBKTTL.DBF. Этот файл содержит рассчитанные бухгалтерские итоги остатков и оборотов по синтетическим счетам и объектам аналитики. Когда размер файла достигает 1.99ГБ (2 147 440 385 байт), начинают сыпаться ошибки: error # -120, error # -110, error # -100, error # -70, error # -60 и т.п. Подробнее про ошибки…
Ошибки появляются при проведении документов или пересчёте бухгалтерских итогов. Программа пытается произвести запись в файл 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С, который выполнит эти и любые другие работы, можете обратиться через контактную форму.
Если Вы хотите заказать услугу «Выполнение регламентных операций (чистка, свёртка, исправление ошибок) и администрирование 1С» (код 2.9). Пожалуйста, ознакомьтесь с прайс-листом и оформите заявку через контактную форму.
Copyright©, «Программист 1С в г.Минске», 10.10.2015
Перепечатка текста и фотографий разрешена при наличии прямой ссылки на источник
|
0 / 0 / 0 Регистрация: 28.11.2008 Сообщений: 35 |
|
|
1 |
|
|
10.01.2009, 12:10. Показов 48151. Ответов 9
Нужна помощь. И потом сообщение — невостановимая ошибка БД… Операционка — сервер 2000 1 Причина в размере файла?
0 |
|
0 / 0 / 0 Регистрация: 07.07.2008 Сообщений: 1,401 |
|
|
10.01.2009, 12:15 |
2 |
|
Сделать копию и на ней провести тестирование и исправление БД. Мож поможет. Если на регистре остатков стоит быстрая обработка движений — можно её убрать, это несколько уменьшит размер файла. Также можно попытаться убрать галку отбор движений у реквизитов регистра, тож уменьшает. Может какой-то процесс действительно занимает эти файлы — тогда при их переименовании система бы ругалась,таким макаром можна проверить. Если работа идёт по сети — может быть дело в ограничении количества одновременно открытых файлов.
0 |
|
1 / 1 / 0 Регистрация: 04.12.2005 Сообщений: 1,588 |
|
|
10.01.2009, 12:28 |
3 |
|
как вариант можно попробовать грохнуть файлы CDX и пускай программа заново индексы простроит
0 |
|
0 / 0 / 0 Регистрация: 28.11.2008 Сообщений: 35 |
|
|
10.01.2009, 18:26 |
4 |
|
Если на регистре остатков стоит быстрая обработка движений — можно её убрать как проверить и убрать?
Может какой-то процесс действительно занимает эти файлы — тогда при их переименовании система бы ругалась,таким макаром можна проверить. не ничто не занимает. Завтра попробую тестирование и исправление сделать… Интересует вопрос именно о размере файла. ща он точно 1.999..ГБ что наводит на мысль о ограничение ОС или 1С 7.7….
0 |
|
1 / 1 / 0 Регистрация: 04.12.2005 Сообщений: 1,588 |
|
|
11.01.2009, 08:45 |
5 |
|
ос — fat32 — 4ГБ, ntfs — еще больше. 1С особых ограничений не накладывает, во всяком случае документально. практически dbf файл такого размера это не есть хорошо!
0 |
|
0 / 0 / 0 Регистрация: 07.07.2008 Сообщений: 1,401 |
|
|
11.01.2009, 10:10 |
6 |
|
Касательно дбф Max. # of records per table 1 billion* * The actual file size (in bytes) cannot exceed 2 gigabytes for single-user or exclusively opened multi-user tables. Shared tables with no indexes or .IDX indexes cannot exceed 1 gigabyte. Shared tables with structural .CDX indexes cannot exceed 2 gigabytes. То бишь не больше двух гигов дбф-ка — это ограничение стандарта дбф. касательно быстрой обработки движений — заходишь через конфигуратор в базу, ищешь нужный регистр, открываешь панель свойств и там под типом регистра стоит галка быстрая обработка движений — её надо отрубить.
0 |
|
0 / 0 / 0 Регистрация: 28.11.2008 Сообщений: 35 |
|
|
11.01.2009, 13:50 |
7 |
|
гхм.. в конфе не используются регистры — их нет…
0 |
|
0 / 0 / 0 Регистрация: 07.07.2008 Сообщений: 1,401 |
|
|
11.01.2009, 15:19 |
8 |
|
Тогда пардон — никак не сожмешь. как только два гига переваливает — начинаются ошипки.
0 |
|
0 / 0 / 0 Регистрация: 28.03.2004 Сообщений: 1,913 |
|
|
11.01.2009, 19:29 |
9 |
|
1SBKTTL — Таблица Итогов
0 |
|
0 / 0 / 0 Регистрация: 28.11.2008 Сообщений: 35 |
|
|
12.01.2009, 07:47 |
10 |
|
1SBKTTL — Таблица Итогов Дело в том, что количество элементов справочника номенклатура уже исчисляется сотнями тысяч, это связанно с тем что товарами являются журналы и газеты, и каждый номер — новая номенклатура…
0 |