1с отсутствует таблица accumrg
Сделайте бекап. Удалите все индексы данного регистра. Пересохраните конфигурацию. Сделайте реиндексацию.
"repair_allow_data_loss - это минимальный уровень исправления для ошибок, найденных DBCC CHECKDB (UPP, repair_rebuild)" Запуститу на копии DBCC CHECKDB ('UPP', REPAIR_ALLOW_DATA_LOSS) для начала.
данные не потеряются, если удалить индексы? Открыла ветку с индексами - там их 6 уникальных некластеризованных и 1 кластеризованный. Их просто удалить.
я читала такую ссылку. в конце ссылки приводится две картинки. Нахожу таблицу "_AccumRg23823", раскрываю ее, нахожу "Индексы" - далее нажимаю "Создать скрипт для индекса" - Используя CREATE - Новое окно редактора запроса При этом открывается окно запроса с текстом запроса: GO /****** Object: Index [_Accum23823_ByDims23843_RTRN] Script Date: 16.12.2015 10:05:44 ******/ CREATE UNIQUE NONCLUSTERED INDEX [_Accum23823_ByDims23843_RTRN] ON [dbo].[_AccumRg23823] ( GO Дальше что я должна сделать?
Дальше удаляйте, а потом пересоздавайте по скрипту. А можно было просто пересохранить конфу. Она сама индексы пересоздаст
Сделала, как по ссылке Создала скрипты для индексов, просто вышло много окон с текстами запросов для 6 некластеризованных индексов и все. затем удалила эти 6 индексов. А как теперь их создать? Затем пишут: "Затем выполним поочередно скрипты по созданию индексов в открытых окнах, попутно закрывая их (чтобы ничего не забыть)." Что это значит? Как сделать?
Т.е. по описанию в ссылке я должна сначала создать скрипты по 6 индексам, сохранить себе их данные, затем индексы удалить и создать их снова, скопировав запросы созданных скриптов, и нажать по каждому индексу выполнить. А при создании нового индекса выбирать те поля, которые указаны в скрипте? Так?
Сделала, запускаю повторно запрос проверки, выдает следующее: Неуточненные транзакции проходят откат. Предварительно выполнение отката: 0%. Неуточненные транзакции проходят откат. Предварительно выполнение отката: 100%. Это хорошо или нет?
как это сделать? все делала на копии. при загрузке базы провела документ, на котором вылетала база - провелся!
Спасибо большое за помощь! А еще вопрос: какая может быть причина, что полетели индексы регистра накопления? Что могло послужить причиной?
А можно было по сути запустить реиндексацию таблиц информационной базы (по сути это и есть манипуляции с dt-ником)? И можно еще спросить здесь же: эта проблема возникла в Центральной базе, а в Периферийной базе вообще можно запускать реиндексацию таблиц информационной базы? И вообще какое еще тестирование можно проводить в Периферийной базе?
Канешна можно. Индексы строго говоря не зависят от базы. Кроме кластерного индекса, тн Прайм Кей. Кластерный индекс это сортировка самой таблицы, столбец который сортируется и есть кластерный индекс. Но в каждой БД, даже если 2 БД одинаковые с точки зрения 1С, сортировка внутри таблиц может быть разной.
Я имею ввиду на будущее потом, вообще ее нужно тестировать? И если да, то какие проверки можно задавать?
Возникает ошибка при попытке провести ряд документов (в частности - списание с расчетного счета) - Ошибка SQL: Таблица не найдена '_AccumRg21395'.
Посмотрел структуру типовой базы того же релиза (3.0.67.74) - там данной таблицы нет. Тестирование и прочие манипуляции не помогают (нашёл статью, где спец включил возможность изменения, удалил объект с кривой таблицей и потом накатил типовой cf-ник, но не знаю какой объект удалять).
Может кто знает что с этим делать или знает какой регистр пишется в таблицу AccumRg21395??
ПолучитьСтруктуруХраненияБазыДанных (GetDBStorageStructureInfo)
Синтаксис:
Тип: Массив.
Массив имен объектов метаданных или массив объектов метаданных, для которых требуется получить структуру таблиц базы данных.
Тип: Булево.
Определяет, в каких терминах выдается информация о структуре хранения.
Истина - в терминах СУБД.
Ложь - в терминах модели базы данных 1С:Предприятия.
Значение по умолчанию: Ложь.
Возвращаемое значение:
Тип: ТаблицаЗначений.
Возвращает таблицу значений с описаниями структуры таблиц, индексов и полей базы данных в терминах модели базы данных 1С:Предприятия или используемой СУБД, в зависимости от значения параметра .
Если параметр не используется, то возвращаемая таблица значений содержит информацию о структуре таблиц базы данных всех объектов метаданных.
Таблица значений включает следующие колонки:
Примечание. Количество и состав таблиц, полей и индексов могут отличаться в зависимости от значения параметра .
Описание:
Получает информацию о структуре таблиц базы данных для переданных в качестве параметра массива имен объектов метаданных или массива объектов метаданных для административных действий с ней.
Сервер, толстый клиент, внешнее соединение.
Примечание:
Следует использовать метод только для административных задач обслуживания базы данных и анализа записей технологического журнала. Не следует применять метод для реализации какой-либо части прикладной функциональности.
При изменениях в версиях часть изменений выполняется не сразу, а во время реструктуризации объектов или полной рекструктуризации. Такие изменения отмечаются в списке изменений. Метод возвращает структуру, которая будет получена после реструктуризации.
Пример:
(0) "Посмотрел структуру типовой базы того же релиза" - надо смотреть структуры ЭТОЙ базы, а не "типовую того же релиза".
(2) Я и этой базы смотрел структуру, как следует из ошибки - данной таблицы нет. Я на тот случай, если база поломана посмотрел типовую базу, там так же нет её. И не пойму в какой момент в таком случае он к ней обращается, что выдает ошибку
"Ошибка SQL Таблица не найдена 'NNNNNNNN'" .
Особого значения не придал, ИБ база работает жалоб не поступает. Спокойно перевел базу на платформу 8.2.
Системный администратор предложил перевести с файловой версии на серверную и вот тут-то всё вспонилось.
- База не тестируется.
- Реструктуризация таблиц информационной базы не выполняется
(В процессе обновления информационной базы произошла критическая ошибка)
- Реструктуризация таблиц информационной базы не выполняется
Первое что пришло в голову тестирование chdbfl.exe, но чудес не произошло
(Ошибок не обнаружено)
Хорошо, сейчас выполню выгрузку базы в файл и далее загрузка в пустую. Ага, как бы не так.
Программа завершена аварийно. Приехали - ждите теперь серверный вариант - "Нет выгрузки, нет и загрузки".
Какая таблица отсутствует нашел из окна "В процессе обновления информационной базы произошла критическая ошибка" в нижней строке состояния программы. Эту таблицу я не использую, следовательно мне повезло- нет необходимости что-то восстанвливать. Но, в принципе, это может быть и справочник и документ. Тогда после восстановления, предполагаю, надо из архивной версии заполнять данные.
=============================================================================================
Критическую Ошибку я победил, всё по порядку:
1. Взял начальную установку конфигурации БП в фирме 1С и установил её себе (пустая база).
2. Выгрузил из начальной установки ИБ (пустой базы) конфигурацию в файл.
3. В ИБ с ошибкой (отсутствует таблица NNNNN) снял конфигурацию с поддержки и разрешил изменение.
Нашел, что это за плохой объект конфигурации и попробовал его удалить (рассказал ранее).
Программа выдала ссылки на этот объект. Зашел по этим ссылкам и удалил из них свой объект.
Далее удалил без помех свой объект и . очень важно .
- обновил конфигурацию базы
- тестировал с исправление ИБ
4. После тестирования загрузил конфигурацию из начальной установки ИБ и снова повторил загрузку в базу измененной
конфигурации и полное тестирование ИБ.
Примечание.
После загрузки конфигурации из начальной установки ИБ программа создала мой ошибочный объект
и установила конфигурацию снова на поддержку с запретом редактирования.
=============================================================================================
Если база открывается то выгрузить для перехода в сервис, во фреше загрузить, потом выгрузить уже в обновленной версии - круто? При тестировании выбери только реструктуризация как варик. Если не чего не поможет WinHex и погнал )))
(9) там нет. если отменить все изм, и реструктуризация не катит, загрузка CF со структурой до обновления не помогает. тогда только hex
(3) выгрузить конфу в файлы, в руте будет файло с идентификатором, по идентификатору находишь в тул1сд че за константа
Если база открывается в режиме предприятия то создаешь пустую базу и выгружаешь все данные через XML.
На битых данных будет падение выгрузки - их пропускаешь
(31) Спасибо, не сомневаюсь. Вопрос только в том чтобы найти нужную. Да ищу, параллельно пробую спрашивать.
(32) Тебе нужно попробовать с помощью Tool_1CD удалить таблицу CONFIGSAVE
По всей видимости твоя база упала в момент реструктуризации.
То есть таблица CONFIG должна быть живая.
(29) >Изначально думал поднять из сф новую базу и воспользоваться ПолучитьСтруктуруХраненияБазыДанных()
В базах даже с одинаковой конфигурацией будут разные идентификаторы.
То есть ПолучитьСтруктуруХраненияБазыДанных() даст разные данные.
это та самая схема в которой нет моей константы? как понять формат этого чтобы корректно внести данные?
таблица _CONST30015 в файле присутвует
(39) таблица CONFIGSAVE пуста, это как я понимаю копия конфигурации которую надо будет применить
(47) Пример как такое делать есть ?
У меня пару месяцев назад был подобный вопрос с базой.
Тоже ругалось на отсутствие в схеме базы данных.
Я не нашел способ редактировать DBSCHEMA и решил задачу выгрузкой данных через XML.
(51) Если нужно и не найдешь стукнись на мыло. Мыло в профиле. Сброшу.
Я не помню уже где скачивал.
(57) это обычный текст, не надо его разбирать
При желании, можно в json конвертнуть или в xml.. только, не за чем
(68) да. не восстанавливает.проверил на 1с8.2. но как-то мне удалось восстановить DBSchema без моего участия. может подменой похожего или пустого и реструктуризацией.
Коллеги, а почему автор не хочет очистить таблицу CONFIGSAVE и просто вернуться к той конфигурации которая была ?
(71)архива с конфой-донором нет.но если типовая то конфу-донора можно сгенерировать.возвожно- это самое простое решение. очистка CONFIGSAVE не поможет. произошло рассогласование метаданных и структуры бд или таблицы проекции метаданных в структуру бд
,кот. хранится в записи dbnames из таблицы params
пока не совсем понимаю в чем различие, правильно ли я понимаю что сами метаданные это то что хранится в таблице CONFIG
структура бд это то что храниться в DBSCHEMA а проекция это то что в храниться в dbnames и dbnames должно соответвовать DBSCHEMA ?
нет. не правильно понимаете . в DBSCHEMA хранятся соответствия типов 1с и бд . и естественно DBSCHEMA должна соответствовать dbnames .но все , о чем я питсал относится к 1с8.2 . в 1с8.3 может быть по-другому.
(72) >если типовая то конфу-донора можно сгенерировать
А разве это не приведет к тому же что и создание новой базы с такой же конфой но при этом у объектов будут другие индентиффикаторы ?
(0) А как ты с этой базой столкнулся ? Может все таки есть какие то бэкапы.
Это какое то реальное безумие обновлять базу при полном отсутствии бэкапов.
(75) структура бд в новой базе может быть другой. задача - привести в соответствие метаданные , dbnames и структуру бд. поскольку тулсиди умеет выгружать-загружать конфигурацию замена конфигурации- более простая операция для файловой базы чем редактирование dbnames или изменение структуры бд.
+(75) а для серверной бд проще изменить структуру бд. и на последнем месте - правка dbnames и DBSCHEMA
Немного разобрался как свзяаны талицы. нашел свою константу в DBNames. Может ктото подскажет как ее отредактировать?
(81 )тулсиди вроде умеет выгружать- загружать таблицы. выгрузите парамс отредактируйте запись DBNames. загрузите обратно. если в DBNames будет абракадебра - то разожмите-сожмите ее c помощью v8unpack
Мне как то попадалась база с такими симптомами, у меня сложилось впечатление что при обновлении базы записалась новая dbNames? а новая dbschema не записалась, поэтому и ругается и даже если если исправите проблему с этой конкретной константой, потом будет другая и еще другая константа, и а потом потом справочник итак далее. ДЛя исправления этого надо ручками прописать dbschema для новых и измененных объектов, а задача эта достатчно муторная. Либо проверить соответствие DBShema - dbNames? и все записи которых нет в DBShema удалить из dbNames. Затем что нибудь изменить в конфе чтобы пошел процесс реструктуризации.
Все это возможно сделать если перевести базу в SQL (у меня сработала выгрузка в dt/загрузка из dt), у меня сложилось мнение что на файловой сделать это нельзя. Хотя я уже не помню, но в SQL легче переписывать эти файлы.
:(
(94) ДЛя исправления этого надо ручками прописать dbschema для новых и измененных объектов, а задача эта достатчно муторная. как сформировать правильную схему?
Либо проверить соответствие DBShema - dbNames? да я пока вижу неторое количество новых констант. Как сопоставить пока не поинмаю только начинаю узучать
сди толс умеет вроде следующее, только как пока я не могу применить, по сути надо номер сопоставить с названиями с одной базе и другой и получить соответвие номеров вот как и поулчить я бы тоже хотел понять.
Поле ввода «Файл соответствия номеров» и кнопка «Замена TREF»
Иногда в процессе восстановления возникает необходимость переноса таблиц из одной базы в другую базу с такой же конфигурацией, но с несовпадающей нумерацией в DBNames. Например, разрушена таблица в центральной базе, но нужная таблица есть в периферийной базе. Кроме того, что в таких базах не совпадают имена таблиц и полей, которую можно решить правкой файла описания таблицы, есть еще проблема несовпадения типов ссылок, которые хранятся в полях с окончанием "TREF". Подробности описаны в разделе "Структура информационной базы 1С". Данный инструмент позволяет произвести замену всех значений во всех таблицах базы в полях с окончанием TREF. Список замен должен содержаться в файле, выбираемом в поле ввода. Файл представляет собой текстовый файл. В каждой строке файла содержатся два числа, разделенных табуляцией. Второе число - заменяемое. Все поля, содержащие такое значение, заменяются на первое число строки.
Все замены производятся без изменения индексов в базе!
Самый простой путь, удаляйте все из DBNames на что ругается (напишите сравнение dbnames и dbshema). Так вы по сути вернетесь к базе до обновления. ТОлько для этого надо еще все конфиги вернуть к релизу до обновления (если это типовая база), то это легко. Если все сделаете верно, то с вероятностью 95 % база снова запустится, и будет как до обновления.
я не знаю с какого релиза обновлялись.
мне вот удаление конкреной константы не помогло. хотя не исключаю что к я уже чет напутал. ладно, завтра со свежей головой
"В процессе обновления информационной базы произошла критическая ошибка. по причине: Ошибка SDBL: Таблица AccumRgAggOpt13937 отсутствует в схеме базы данных (pos=99)" Скуль база. Пробовал разные ТиИ, выгрузки загрузки. Подозреваю, что дело в том, что некоторые регистры превращал из остаточных в оборотные. Что можно сделать?
что бэкап? VS SQL 2008 R2 - вряд ли кэш. Переносил на сервак выгрузкой dtника - та же тема. - как обновить? Идет как раз обновление базы на другой релиз.
Ошибка SDBL: Таблица AccumRgAggOpt13937 отсутствует в схеме базы данных (pos=99) как бе намекает, что в скуле она есть
что вернет такой запрос use вашаБАЗА select PATINDEX(N'%AccumRgAggOpt13937%', SerializedData) nompos from ( from
посмотрите с помощью какойнибуть обработки типа StrBaseSQL к камим метаданным относится AccumRgAggOpt13937 добавте туда реквизит, чтобы реструктуризировать именно эту таблицу.
Обработка СтруктураТаблицSQL не показыват такой таблицы.StrBaseSQL . пока не разобрался, как там строку соединения настроить.
у самого регистра номер чуть меньше, короче юзай обработку, либо сам пиши быстренько Глобальный контекст (Global context) ПолучитьСтруктуруХраненияБазыДанных
Где такую взять? Знать бы что за регистр, мог бы измерения, настройки агрегатов менять, и т.п. а то и удалить его.
эти обработки могут не знать о агрегатах. поэтому не выводить их попробуйте поскать в ПолучитьСтруктуруХраненияБазыДанных.ВыбратьСтроку или с помощью найти
могут и не знать, но номер чуть меньше 13937 покажет регистр. не проверял на агрегатах. Они так и сделаны - ПолучитьСтруктуруХраненияБазыДанных ушло
Получи струтуру хранения,найди свою таблицу,вспомни что ты с ней делал и посторайся вернуть её к тому виду в котором она хранилась
Была такая фигня как раз при смене типа регистра (из оборотного в остатки). Дого бился. Плюнул, удалил регистр и создал заново. Потом перепровел документы.
если она пустая снеси нафиг,если нет верни на место ,если и это не поможет выгрузи её в ХМл,Удали нафиг и создай точно с таким же Именем регистр.После этого проверь где он ходил потому что скорее всего снесутся регистраторы и восстанови обратно.После всего Отключи пересчет остатков для того чтоб быстрее грузануть ХМЛ и все получится надеюсь
З.ы. показывает конечно сохранённую конфу ИБ, а не обновлённую уже (обновится ты и не можеш тем более). Судя по склоняюсь что добавили агрегаты в регистр. сносить
Что за обновление такое было хоть? З.ы. щас не поздно откатится на сохранённую конфу, и потом обновлять не добавляя агрегаты например, их можно добавить после
щас можно вернутся к конфе ИБ, и обновить без добавления агрегатов и без превращения оборотного в остаточный (если такое имеет место). сотальное добавить позже.
ок. Попробую сохранить цф, запустить обновления, и смотреть, какие изменения, связанные с агрегатами имеют место.
всмысле сохранить цф? щас не обновлена база, Конфигурация - Вернуть конфу БД, вернёшся назад, где не должно быть ошибки
я так и не понял, ты можешь вернутся к конфе БД щас? откатись, и заново потом накатывай обновление, может глюк просто
Объясните мне еще про технологический журнал. На партнерском форуме пишут про папку rphost_XXXX, которая у меня не находится. Где ее искать, и почему может не создаваться?
rphost это скулевский процесс.(глянь диспетчере).Он никакого отношения к твоей таблице не имеет.Лучше снеси её к чертям из скуля))
Файлы технологического журнала серверной части должны лежать в таком каталогу. И не скулевский это процесс, а сервера 1с. Таблицы такой нету в скуле.
Читайте также: