1sbkttl dbf ошибка 120

Category:

• 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С всё равно что-то пишется. Оказалось для того чтобы этого не происходило, нужно «установить расчёт» (управление бухгалтерскими итогами) куда-нибудь назад, чтобы удаляемые документы были позже по дате проведения.

Помечать на удаление несколько десятков тысяч документов пришлось самописной обработкой. Ну а дальше уже всё легко: пометка на удаление всей номенклатуры, удаление помеченых объектов, снятие пометки удаления с оставшейся номенклатуры,  проведение бухгалтерских справок с проводками ввода остатков, полный пересчёт итогов и упаковка таблиц базы данных.

На весь этот «путь к успеху», в моём случае, было потрачено несколько суток, но это в основном из-за большого количества номенклатуры и из-за метода «научного тыка».

Возникает ошибка Codebase Error -120 ☑ 0

spaiker

11.11.10

✎

08:45

При открытии бызв и попытка перенести остатки на слдедующий месяц возникает ошибка Codebase Error -120. Как исправить?

Характеристика базы:

1с.Тис 7

Тип: файловая

Объем: >5Гб

1

Табуретко

11.11.10

✎

08:47

ТИИ?

2

andrewks

11.11.10

✎

08:48

dbf/cdx больше гига есть?

3

spaiker

11.11.10

✎

08:49

RG9480.DBF весит 2 гига и на него и ругаетьтсяь пишет типа неможет произвести чтение

4

Табуретко

11.11.10

✎

08:51

при таких обьемах наверное следует хотябы уменьшить период хранения остатков

5

andrewks

11.11.10

✎

08:51

(3) дотянул. надо было или на sql переходить, или базу резать. теперь патч надо ставить

6

ДенисЧ

11.11.10

✎

08:52

Снеси все rg* и пересчитай итоги. Должно немного уменьшиться.

7

spaiker

11.11.10

✎

08:52

какой патч? скажите где взять плиз

8

spaiker

11.11.10

✎

08:53

ДенисЧ а поподробнее пожалйста можно?

9

ДенисЧ

11.11.10

✎

08:54

(8) куда уж подробней…
Удали из каталога базы все файлы rg*.*
зайди в конфигуратор — ТиИ — пересчет итогов

10

Табуретко

11.11.10

✎

08:54

(9)+бекап

11

andrewks

11.11.10

✎

08:56

+(9) но поможет это ненадолго. срочно надо или резать, или на sql, т.к. патч, насколько я читал, пашет не идеально

12

spaiker

11.11.10

✎

08:57

если удалить эти файлы данные останутьс целыми?

13

andrewks

11.11.10

✎

08:57

(12) да

14

Табуретко

11.11.10

✎

08:57

это файлы хранения регистров… они востановятся при ТИИ

15

Табуретко

11.11.10

✎

08:58

но лишний бэкап не будет лишним (c)

16

spaiker

11.11.10

✎

09:01

Спасибо всем

17

filh

11.11.10

✎

09:04

RA9480.DBF сколько весит?

18

spaiker

11.11.10

✎

09:04

2 гига

19

andrewks

11.11.10

✎

09:05

20

filh

11.11.10

✎

09:05

(18) т.е. у тебя RG9480.DBF и RA9480.DBF по 2 гига?

21

spaiker

11.11.10

✎

09:05

RA9480.DBF 58 мб

22

filh

11.11.10

✎

09:09

(21) ну…у тебя регистр не закрывается.

23

filh

11.11.10

✎

09:09

+22
что за регистр, посмотри в dd

24

spaiker

11.11.10

✎

09:11

где посмотреть? что то я запутался если чесно

25

andrewks

11.11.10

✎

09:12

(22) +100000

26

filh

11.11.10

✎

09:13

(24) открой файл 1Cv7.DD и найди строчки с T=RA9480

27

andrewks

11.11.10

✎

09:13

(24) 1cv7.dd найди T=RA9480

28

spaiker

11.11.10

✎

09:13

а чем фал открыть?

29

andrewks

11.11.10

✎

09:13

(28)

30

ДенисЧ

11.11.10

✎

09:14

нотепадом.
Или фаром. Или тоталкомандиром.

31

spaiker

11.11.10

✎

09:15

#==TABLE no 339    : Регистр (Дв.) КДРДокументы
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RA9480  |Регистр (Дв.) КДРДокументы    |A          |RA9480     |1        
#——Fields——-
# Name      |Descr               |Type|Length|Precision
F=IDDOC     |ID Document’s       |C   |9     |0        
F=LINENO    |LineNo              |N   |4     |0        
F=ACTNO     |Action No           |N   |6     |0        
F=DEBKRED   |Flag Debet/Kredit   |N   |1     |0        
F=SP9474    |(P)СФ               |C   |13    |0        
F=SP9475    |(P)Номенклатура     |C   |9     |0        
F=SP9476    |(P)Количество       |N   |19    |6        
F=SP9477    |(P)СуммаБезНДС      |N   |19    |6        
F=SP9478    |(P)СуммаНДС         |N   |19    |6        
F=SP9479    |(P)СуммаОплаченного |N   |19    |6        
#—-Indexes——
# Name     |Descr         |Unique|Indexed fields                                              |DBName    
I=IDLINE   |of IDDOC+LineN|0     |IDDOC,LINENO,ACTNO                                          |IDLINE    
#

32

Табуретко

11.11.10

✎

09:17

Уж точно не типовая ТИС

33

andrewks

11.11.10

✎

09:18

че у тебя в Рег.КДРДокументы ???

34

spaiker

11.11.10

✎

09:18

не база полностью нетиповая ..ее писали под нас

35

andrewks

11.11.10

✎

09:21

(34) таким писателям надо руки пообрывать. опять какую-то структуру сунули в регистр остатков, вместо того чтобы сделать по-человечьи

36

spaiker

11.11.10

✎

09:22

andrewks
абсолюьно с тобой с этим согласен

37

filh

11.11.10

✎

09:25

(31) а покажи еще RG9480

38

spaiker

11.11.10

✎

09:26

#==TABLE no 338    : Регистр КДРДокументы
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RG9480  |Регистр КДРДокументы          |A          |RG9480     |1        
#——Fields——-
# Name      |Descr               |Type|Length|Precision
F=PERIOD    |Period Registr      |D   |8     |0        
F=SP9474    |(P)СФ               |C   |13    |0        
F=SP9475    |(P)Номенклатура     |C   |9     |0        
F=SP9476    |(P)Количество       |N   |19    |6        
F=SP9477    |(P)СуммаБезНДС      |N   |19    |6        
F=SP9478    |(P)СуммаНДС         |N   |19    |6        
F=SP9479    |(P)СуммаОплаченного |N   |19    |6        
#—-Indexes——
# Name     |Descr         |Unique|Indexed fields                                              |DBName    
I=PROP     |PERIOD+PROP   |0     |PERIOD,SP9474,SP9475                                        |PROP      
#

39

kiruha

11.11.10

✎

09:31

40

filh

11.11.10

✎

09:34

(38) а что за отчеты формируете по «кадровые документы» или еще как…

41

andrewks

11.11.10

✎

09:34

(39) не факт что остатки нулевые и не факт что это поможет. скорее всего тут просто ошибочно выбрали рег.остатков для какой-то хни, которую надо было по-другому хранить

42

Шурик71

11.11.10

✎

09:40

43

spaiker

11.11.10

✎

09:48

я удалил все R*.*. сделал пересчет итогов..помогло…

44

Табуретко

11.11.10

✎

09:51

и каков теперь вес указанных файлов? не корысти ради, интереса для…

45

Шурик71

11.11.10

✎

09:52

Хотя не совсем, прикинул — за лет эдак 7-8 работы реально соорудить (3 года это теоретический вариант, когда эти 56 мб набили  в начале и забыли, и они каждый месяц падают себе из RA на RG)

46

spaiker

11.11.10

✎

09:53

все R весят 254 кб

47

andrewks

11.11.10

✎

09:54

(46) O_O

48

Табуретко

11.11.10

✎

09:54

чето както оно даже подозрительно…

49

Шурик71

11.11.10

✎

09:54

50

Шурик71

11.11.10

✎

09:56

Жесть… даже совет в форуме прочитать правильно не может…

51

filh

11.11.10

✎

09:56

(46) перепроводи доки, либо бекап

52

filh

11.11.10

✎

09:59

+51
лучше бекап, т.к. не факт, что не проводили доки взад.

53

1Сергей

11.11.10

✎

10:14

(52) он уже все регистры грохнул. Только бекап спасет теперь

54

andrewks

11.11.10

✎

10:15

(53) не только. перепроведение тоже рулит. правда, времени уйдет…

55

Табуретко

11.11.10

✎

10:21

(15)+100 если читал вниматочно…

56

kiruha

11.11.10

✎

10:26

Пригласите спеца — сами похоже не разрулите

57

Эльниньо

11.11.10

✎

10:30

Форум надо почитывать периодически, дабы на грабли не наступать.

Перейти к контенту

Если база данных 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

Перепечатка текста и фотографий разрешена при наличии прямой ссылки на источник