Имя: Пароль:
1C
 
Если грубо очистить таблицу "AccRgAT21781" она пересчитается?
0 ФормаДокумента
 
28.08.18
21:16
"AccRgAT21781" = "РегистрБухгалтерии.Хозрасчетный" = "ИтогиПоСчетамССубконто2"

Вроде бы это итоги и полным пересчетом должны перезаполнится.
Сейчас при пересчете вываливается. как и при тестировании (1с и sql), как и при выгрузке.

"Идентификатор объекта 1886772112, идентификатор индекса 1, идентификатор секции 72058030513848320, идентификатор единицы размещения 72058055402520576 (тип In-row data): не удалось обработать страницу (1:13745694). Для получения подробных сведений просмотрите сообщения о других ошибках.
Ошибка таблицы: идентификатор объекта 1886772112, идентификатор индекса 1, идентификатор секции 72058030513848320, идентификатор единицы размещения 72058055402520576 (тип In-row data), страница (1:13745694). Тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не прошел. Значения - 12716041 и -4.
Ошибка таблицы: идентификатор объекта 1886772112, идентификатор индекса 1, идентификатор секции 72058030513848320, идентификатор единицы размещения 72058055402520576 (тип In-row data). Страница (1:13745694) не была обнаружена при просмотре, хотя ее родитель (1:13742094) и предыдущая страница (1:13745693) ссылаются на нее. Проверьте предыдущие ошибки.
Ошибка таблицы: идентификатор объекта 1886772112, идентификатор индекса 1, идентификатор секции 72058030513848320, идентификатор единицы размещения 72058055402520576 (тип In-row data). Отсутствует ссылка на страницу (1:13745695) с предыдущей страницы (1:13745694). Возможна ошибка связывания цепочек.
CHECKDB обнаружил 0 ошибок размещения и 4 ошибок согласованности в таблице "_AccRgAT21781" (идентификатор объекта 1886772112).
CHECKDB обнаружил 0 ошибок размещения и 4 ошибок согласованности в базе данных "SC".

ПС копия есть.
1 Aleksey
 
28.08.18
21:36
Я чистил на рабочей базе и итоги и не только Как удалить "фантомные" записи в таблице итогов средствами 1С

Проблем небыло
2 timurhv
 
28.08.18
21:43
(0) Я бы на копии очистил все таблицы с итогами хозрасчетного регистра, а не только который в шапке и пересчитал итоги.
3 ФормаДокумента
 
28.08.18
22:21
(1) спасибо
4 МихаилМ
 
29.08.18
00:39
(0) начните с chkdsk
5 unregistered
 
29.08.18
01:18
(0) По идее проблем быть не должно.
Но для начала можно было бы попробовать просто выключить итоги и текущие итоги, а потом обратно их включить. По идее итоги очищаются и перечитываются.
Так же можно попробовать утилиту административной консоли 1cv8a
https://its.1c.ru/db/v838doc/bookmark/adm/TI000000735
Утилита административной консоли (1cv8a) предназначена для ускорения проверки и исправления определенных проблем:
Тестирование и исправление для таблиц узлов панов обмена.
Тестирование и исправление хеш-полей таблиц информационной базы.
Утилита административной консоли позволяет исправлять некоторые проблемы, возникающие с информационной базой, без запуска конфигуратора и за более короткое время. Это обусловлено тем, что утилита административной консоли занимается обработкой только проблемных объектов и при этом выполняется ограниченный набор исправлений.
6 ФормаДокумента
 
29.08.18
06:14
(4) DBCC CHECKDB (База, repair_rebuild) вываливается также с (0)
DBCC CHECKDB (База, REPAIR_ALLOW_DATA_LOSS) пока очкую
7 ФормаДокумента
 
29.08.18
06:29
(5) спасибо. попробую. вроде как раз хэши слетели
"Тестирование и исправление хеш-полей таблиц информационной базы."
8 ФормаДокумента
 
29.08.18
07:06
чтото консоль вываливается
"Сигнатура проблемы:
  Имя события проблемы:    APPCRASH
  Имя приложения:    1cv8a.exe
  Версия приложения:    8.3.12.1567
  Отметка времени приложения:    5b3f426b
  Имя модуля с ошибкой:    basic.dll
  Версия модуля с ошибкой:    8.3.12.1567
  Отметка времени модуля с ошибкой:    5b3f41bb
  Код исключения:    c0000005
  Смещение исключения:    0048eaad
  Версия ОС:    6.1.7601.2.1.0.18.10
  Код языка:    1049"
9 Cool_Profi
 
29.08.18
07:26
(8) Дык у тебя файл БД битый....
Скопируй его в новую базу, и там уже попробуй чек с REPAIR_ALLOW_DATA_LOSS
Потом пересчитай итоги и проверь
10 triviumfan
 
29.08.18
09:07
(1) также делал, проблем не было выявлено, хотя "страхово" :)
11 Serg_1960
 
29.08.18
09:16
(0) Я удалял таблицы с так называемой "служебной информацией" (средствами SQL), в т.ч. журналы документов. При первом последующем запуске сеанса 1С, таблицы бы восстановлены и перезаполнены. Правда давно это было, сейчас платформа уже "не та".

А у вас банальное разрушение данных в таблицах SQL - на сервере SQL куда больше (чем в 1С) средств восстановления кроме удаления - проверяйте и лечите базу.
12 Aleksey
 
29.08.18
09:18
(11) а смысл лечить с неясным результатом. Грохнул, пересчитал и спи отдыхай
13 Serg_1960
 
29.08.18
11:52
(12) А потом ещё раз "грохнул и спи спокойно" и ещё раз? Так тоже может быть. Надо проверять базу и пробовать лечить, имхо.
14 МихаилМ
 
29.08.18
12:43
(6)найдите разницу между
chkdsk и CHECKDB
15 DSSS
 
29.08.18
12:45
Всегда нужно чистить таблицы только МЯГКО. Никаких грубостей таблицы не переносят
16 Aleksey
 
29.08.18
15:50
(13) Ну да лучше день потерять в поисках причины, потом грохнутьи спать спокойно
Чтобы обнаруживать ошибки, программист должен иметь ум, которому доставляет удовольствие находить изъяны там, где, казалось, царят красота и совершенство. Фредерик Брукс-младший