1с commonsettings что за таблица

Обновлено: 08.07.2024

Объект 1С "ХранилищеСистемныхНастроек" я называю "внутренним кэшем" 1С, он содержит объект менеджера стандартного хранилища настроек, предназначенный для доступа к системным настройкам.
При модицикации конфигурации иногда не достаточно очистить внешний кэш 1С, т.е. файлы созданные платформой 1С на жестком диске для хранения настроек пользователя, и требуется дополнительно очистить "внутренний кэш" 1С с чем и справится представленная разработка!

Описание

Обработка «Хранилище системных настроек» представляет собой полностью автономное решение, с точки зрения встраивания в любую конфигурацию, как на обычных, так и на управляемых формах! А версия платформы начиная с 8.2 не играет роли! В коде не используются синхронные и модальные вызовы!

Обработка показывает работу с методами типа данных:

СтандартноеХранилищеНастроекМенеджер (StandardSettingsStorageManager)
Методы:
Выбрать (Select)
Загрузить (Load)
ПолучитьОписание (GetDescription)
ПолучитьСписок (GetList)
Сохранить (Save)
Удалить (Delete)
УстановитьОписание (SetDescription)
Описание:
Объекты этого типа предназначены для доступа к настройкам, хранящимся в стандартном хранилище.
Для доступа к настройкам вариантов отчетов объект этого типа должен быть получен из свойства глобального контекста ХранилищеВариантовОтчетов.
Для доступа к пользовательским настройкам отчетов объект этого типа должен быть получен из свойства глобального контекста ХранилищеПользовательскихНастроекОтчетов.
Для доступа к пользовательским настройкам данных форм объект этого типа должен быть получен из свойства глобального контекста ХранилищеНастроекДанныхФорм.
Для доступа к общим настройкам объект этого типа должен быть получен из свойства глобального контекста ХранилищеОбщихНастроек.
Для доступа к системным настройкам объект этого типа должен быть получен из свойства глобального контекста ХранилищеСистемныхНастроек.
Для доступа к пользовательским настройкам динамических списков объект этого типа должен быть получен из свойства глобального контекста ХранилищеПользовательскихНастроекДинамическихСписков.
Доступность:
Сервер, толстый клиент, внешнее соединение.
См. также:
Глобальный контекст, свойство ХранилищеСистемныхНастроек

Весь функционал проиллюстрирован в скриншотах.

Внимание! Имя пользователя должно совпадать с именем пользователя ИБ! Иначе кнопка "Получить настройки пользователя" будет работать не корректно и часть функционала не сработает. Но если переименовывать пользователей проблематично просто используйте только кнопку "Получить настройки всех пользователей"!

Обновление от 22.04.2020
Переработан код, чтобы избавиться от ошибки формата потока. Данная ошибка связана с тем, что платформа не может отобразить тип данных. Поэтому такие настройки будут исключены из вывода на форму обработки. Дополнительно отправлен запрос в 1С на доработку, ошибка воспроизводится на 1С:Предприятие 8.3.13.1690, 8.3.15.1830, 8.3.17.1386, 8.3.17.1549 .
Ответ ТП от 02.07.2020:
Есть предположение, что размер получаемых настроек превышает 2Gb, и в последующем платформа падает при попытке сериализовать данные (при передаче этого объема данных в качестве параметра). Вероятно объем настроек одного (или нескольких) из пользователей весьма значителен.

Решения проблемы нет, посоветовали не хранить такой объем данных в настройках. Продолжение следует.

Ошибка при вызове метода контекста (Следующий)
Пока Выборка.Следующий() Цикл
по причине:
Ошибка формата объекта настроек
по причине:
Ошибка формата потока

Итак, перед нами "мёртвая" файловая база. Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.

1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки".

Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). "Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.

1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS - таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA - схема (структура) БД
_USERSWORKHISTORY - история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS - содержит файлы с параметрами БД
FILES - содержит прочие системные (служебные) файлы
CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME - имя файла
CREATION/MODIFIED - дата создания/изменения
ATTRIBUTES - атрибуты
DATASIZE - размер файла
BINARYDATA - содержимое файла (двоичные данные)

Теперь мы понимаем, что записи в ТЖ типа
22:42.0169-1,DBV8DBEng,2,process=1cv8,Trans=0,Func=selectFileName,FileName=ibparams.inf
22:42.0170-3,DBV8DBEng,1,process=1cv8,Trans=0,Func=readFile,CatName=Params,FileName=ibparams.inf
означают чтение файла "ibparams.inf" из таблицы PARAMS.

3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).

При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ".new" - их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.

5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.

Загрузив нашу базу в систему restoration-base-1c8, мы можем иследовать список таблиц:

а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:

Просмотр записей таблиц, к сожалению, не реализован.

На этом наш список, а также сам этап обследования заканчивается. Аккуратно фиксируем и систематизируем всю собранную информацию, которую мы будем использовать далее, в процессе "лечения". Конкретные, наиболее типичные проблемные ситуации и способы их устранения будут рассмотрены в следующих статьях.

Загрузив нашу базу в систему restoration-base-1c8, мы можем иследовать список таблиц:

а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:

Просмотр записей таблиц, к сожалению, не реализован.

Решаемая обработкой проблема появилась при обновлении в релизах платформы 8.3.15
О природе ее возникновения можно только догадываться, поскольку на более поздних релизах такая ситуация не является ошибкой.
Дело в том, что начиная с указанного релиза 1с при проверке состояния базы проверяет, уникальность каждого номера таблиц, а до этого, для "правильности" было достаточно, чтобы уникальность сохранялась для отдельного вида таблиц. Т.е. проверялась отдельно уникальность для справочников, документов, регистров и прочее. Какой из релизов платформы напортачил при обновлении конфигураций неясно, но релиз довольно древний.

Если вы словили такую ошибку:
**************************
Ошибка SDBL:
Ошибка обновления конфигурации базы данных. Для одного ссылочного кода существует более одной таблицы в базе данных.

Имена таблиц с кодом .
**************************
Далее перечисляются пары таблиц, которые имеют одинаковый номер.
То эта обработка должна помочь. Запускать ее можно в любой базе на управляемых формах, только не в той, что исправляется.

Шаг 1. Указать параметры доступа к базе SQL. Перейдите на вторую закладку

Шаг 2. Файлы исходной базы. Под файлами понимаем текст имен и текст схемы. На рис. 2 показаны как они выглядят, но на этом шаге поля будут пустыми, их заполнит обработка после нажатия на указанную кнопку. Обработка считывает схему прямо через sql-запрос.

Шаг 3. Таблицы корректировки номеров. Пользователю требуется для каждой пары определить таблицу, которую он будет перенумеровывать. Требуется указать тип таблицы и тот злополучный неуникальный ссылочный код. Новый ссылочный код обработка укажет сама, после выполнения этого шага можно вернуться и посмотреть его. На рисунке 3 ссылочный код уже указан для наглядности, но при первом прохождении эту колонку заполнять не нужно. Он сохранился на рисунке, т.к. вся таблица сохраняется автоматически. В любом случае этот номер будет обновлен выполнением команды по кнопке. В этой версии добавилась возможность отметить те строки которые будут участвовать, остальные сохранятся, но участвовать не будут. На этом шаге обработка формирует новые файлы схемы. При выборе в паре таблицы для переномерования предпочтение следует отдавать перечислениям, константам.
В нижней таблице будут добавлены строки с именами таблиц табличных частей.

Рекомендуется в случае подобных пар:

Имена таблиц с кодом 28: BPrPoints28, ExtensionsRestructNGS

Совершенно безопасно разлепить эту пару второй таблицей. В схеме она не числится, нашел свободный код 16 и заменил вручную в таблице имен. Никаких переименований таблиц базы не потребуется:

Шаг 5. Выполнить команды SQL. Подготовленный список операторов переименует таблицы.

На этом работа обработки заканчивается. Исправленную Базу следует проверить в конфигураторе. Администрирование, Тестирование и исправление, пункт Реструктуризация информационной базы. Эта процедура переименует все индексы обработанных таблиц, а так же статистики таблиц.
Поскольку 1с может использовать кэш, а в этом кэше может сохраниться старая схема, то следует либо освободиться от кэша (сервера и клиента), либо (как некоторые освобождаются от кэша) удалить базу без изменения базы SQL, а потом создать новую базу с указанием на прежнюю базу SQL. У меня в конфигураторе конфигурация была закрыта, кэш мне не помешал.
В общем случае, даже ошибка в таблице на шаге 3 не должно приводить к порче схемы (базы), просто если указать не ту таблицу (тип и номер) она будет переименована и в схеме и в базе, что не возбраняется. Просто проблема не устранится.

Предупреждение об ответственности.
Использование обработки только под Вашу ответственность, не забывайте про бэкапы и тестирование результатов. Не исключена ситуация, которая не учитывает данная версия обработки и методики, которую она реализует.

P.S. оказалось не понятно из описания и следует сфокусировать внимание:

1. Запускать обработку нужно в другой базе, не в той, которую исправляете. Обработка работает непосредственно с MS SQL, а не с базой текущего приложения.

2. Если основная конфигурация изменена, то нужно вернуться к конфигурации базы данных.

3. Для результата нужно обрабатывать сразу все пары, нет смысла устраивать цикл запусков обработки.

Обработка тестировалась на релизе платформы: 1С:Предприятие 8.3 (8.3.15.1830).

Читайте также: