Sql 1с тип документа

Обновлено: 04.07.2024

Всем доброго дня, вопрос заключается в следующем.
Есть необходимость вытащить из sql таблиц 1С8.1 информацию по одному регистру сведений.

select top 2 * from _inforeg18126
дает следующее:

_Fld18127_TYPE _Fld18127_RTRef _Fld18127_RRRef _Fld18128

Знаю что данный регистр сведений содержит в себе ссылки на различные элементы справочников, докумнто и прочее.

Как понять на какой тип объекта метаданных ссылаются элементы?
Например, в приведенном выше запросе что означает ссылка 0x000000A3?
Есть ли таблица в которой хранится соответсвие шестнадцатиричного значения и наименования таблицы?

(0) Найди эту запись в 1С и посмотри.
А вообще, это противоречит лицензионному соглашению.
Знаю, но нужно восстановить некоторые данные из битой базы.
Увы, других вариантов нет. :(

Записей в регистре около 30 000 не вариант каждую запись искать в 1С.
Нужно понять принцип ссылок в этом регистре, остально дело за t-sql.
Вот только не получается понять.

Есть у кого-либо еще идеи??

(0) вначале разбираешься со структурой БД (какая таблица к каким методанным 1С относится. Тогда поймёшь какой именно тип данных находится в том или ином столбце и соответственно уже поймёшь с какой таблицей сиквела он связан (опять же по структуре хранения БД в сиквеле)

Во время перепроведения документов был сбой по питанию, в итоге база вывалилась в Suspect, удалось ее поднять, но в результате получили частичную потерю информации.

Есть еще одна sql база, в которой вертится мобильная торговля (Оптимум, мож кто слышал).

Так вот, связь объектов между этими двумя базами - это мой регистр сведений.
После падения базы 1С, выгрузил ее из центральной заново, но пришлось пересоздать базу Оптимум так как регистр сведений неходит в плане обмена и оказался пустым.

Вот теперь нужно восстановить потерянные ссылки на объекты из этого регистра.

Со структурй проблем нет, знаю что где лежит, но не могу сделать
так есть обработка в инете которая показывает какое поле есть кто

(7) это двоичные данные ежли че. в них храняться ид-шники. Сами ид-ники это строка но они преобразованы в бинари.

В 8ке для хранения составных типов используется структура хранения данных в 3х полях. Видимо твой случай. Где-то была статья но точно сейчас не скажу где.

select top 2 *, CAST(_Fld18127_TYPE as nvarchar(max)) from _inforeg18126

интересно что покажет?

Если вы имеете ввиду обработку, которая показывает структуру базы данных, то это не то что нужно.
Эта обработка может показать только соответствие объектов метаданных 1с таблицам в sql, с указанием полей sql таблиц, но вот описание ссылок элементов на другие элементы таблиц sql я к сожалению не нашел.

Запрос
select top 2 *, CAST(_Fld18127_TYPE as nvarchar(max)) from _inforeg18126

Решил написать статью о том, как вытягивать данные из 1С путем SQL запросов. Все нижесказанное касается 1С версии 8.2, оно также должно работать и в 1С версии 8.1. Особое внимание уделено проблеме с извлечением заголовков перечислений.

В идеале выборку данных из 1С должен делать 1С-программист. Хорошо, если он создаст обработку, которая выдаст данные в так называемую «буферную базу»: csv файлы, таблицы в SQL – что угодно. Проектировщик ХД и ETL должен брать данные из буфера.

В этом случае все работает предельно хорошо: зоны ответственности разделены, если найдена ошибка в данных отчета – ее вначале ищут в кубе, если в кубе все ОК – ищут в ХД, если в ХД все ОК – ищут в ETL, если в ETL все хорошо – значит пускай 1С-программист сам разбирается где у него ошибка в обработке, заполняющей «буферную БД».

Но не всегда такой способ доступен. Бывает, что 1С-специалиста либо вообще нет, либо слишком занят, либо мощностей железа не хватает, чтобы «выталкивать» данные из 1С с помощью обработки. И остается одно – делать извлечение данных с помощью SQL запросов.

Вот это собственно и есть этот способ – «сделать SQL запрос на 1С-базу». Главная задача – корректно написать сами запросы. Я думаю, ни для кого не есть секретом, что в 1С структура данных «хитрая», и что поля и таблицы имеют замысловатые названия. Задача проектировщика ETL – вытянуть данные из этой структуры.

Просмотр метаданных

Существуют обработки, дающие возможность просмотреть то, какие поля справочников/документов в каких таблицах/полях базы данных находятся.

Здесь Вы можете скачать несколько таких обработок (которые мы «отфильтровали» путем перебора десяток подобных, выбрав наилучшие). Они делают почти одно и то же – позволяют посмотреть все поля, понять какое поле на какой справочник ведет, и даже предлагают автоматически построить запрос:

Таким образом, начинаем исследовать нужные нам документы:

Дальше открываем любой из них, и находим то, куда он записывается – в какие регистры:

Ну а дальше найти этот регистр и сгенерировать SQL запрос с помощью показанных выше обработок (как на первом рисунке) не составляет труда.

Мы делаем как правило два уровня SQL запросов: «нижний уровень» — вьюхи для переименования полей, «верхний уровень» – вьюхи, которые берут данные из нижнего уровня, и уже они делают необходимые джойны.

Перечисления

Есть одна большая проблема – это перечисления. Пример:

И теперь если попытаться вытянуть это поле из базы напрямую, то получим вот что:

Да, мы нашли где заголовки перечислений сидят: таблица называется Config, в ней – image поля, в которых сидит зазипованный набор байт, который если раззиповать – получим непонятной структуры набор символов, разделителей и т.д. К сожалению, этот формат данных не документирован.

Вы можете скачать ее отсюда.

Запускается вот так:

Делает следующее: коннектится к 1С с помощью COM, берет оттуда все перечисления, и кладет их в указанную вами таблицу указанной базы, предварительно почистив ее. Таблица должна иметь следующую структуру

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

Если у Вас будут замечания или дополнительные идеи – все они с радостью принимаются, пишите на ibobak at bitimpulse dot com.

При возникновении необходимости миграции с одной конфигурации поставщика на другую, либо при обновлении доработанной конфигурации, если Поставщик позднее добавил тот объект, что был у нас добавлен самостоятельно, может оказаться, что старый и новый объекты имеют разные внутренние идентификаторы. При сравнении/объединении конфигураций видно, что старый документ не находит соответствие с новым, так как у них различные внутренние идентификаторы метаданных, а при загрузке (обновлении) новой конфигурации поставщика старый документ удаляется вместе со всеми введенными документами.

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

А. Перенос удалившихся документов после обновления конфигурации в новый объект метаданных с помощью правил обмена (данный способ рекомендует использовать 1С);

Б. Использование правил настройки сравнения/объединения конфигураций. При этом можно настроить соответствие между старым и новым объектом метаданных. В пользовательской базе останется старый объект (со старым УИДом), а при сравнении/объединении он будет модифицироваться изменениями нового объекта поставщика. Но при этом объект останется со старым УИДом и на поддержку не встанет.

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

Разберем подробно вариант "В".

Данная статья описывает лишь принцип работы с данными. Осуществлять вручную подмену УИДов, в особенности для объектов с большим числом реквизитов, — достаточно трудоемко и имеет смысл автоматизировать данный процесс.

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