FeeL86ZooNto all

на ежедневной основе мне надо тянуть инфу с 1С-ки по проведенным документам и кое-каким справочникам



проще всего средствами 1С выгружать в xml, а далее делай с ним, что хочешь. Напрямую с базой работать устанешь данные преобразовывать.

Я заметил, что работающие с 1С делятся на 2 категории:
1. "...Данные напрямую из 1С-SQL тащить сложно неимоверно, все запутано, требует преобразований данных, и вообще, нанимайте специалиста и работайте через СОМ или xml, и хрен с ним что это тормознуто донельзя..."
2. Просто читают, да и не только читают но и пишут напрямую. Огромное количество примеров этому можно увидеть у соседей в форуме по MS SQL.

Я нахожусь во второй категории. Совет топипикстартеру: вот в этом форуме: Структура таблиц БД 1С . Потратьте 1 день на разбор структуры. В 1С8, кстати, структура данных уже вполне вменяемая.

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

Да, изменение метаданных это проблема, но кто сказал, что при изменениии метаданных не нужно менять скрипты СОМ-соединений?
Согласен, конечно, что меньше изменений делать нужно.
Но ведь можно предложенную выше обработку усовершенствовать таким образом, чтобы она создавала скрипты View на таблицах 1С, с алиасами к полям, кторые одновременно являются реквизитами объектов хранения данных. В этом случае, при изменении метаданных необходимо будет только пересоздать эти View, дальнейшая трудоемкость ликвидации последствий изменения метаданных точно такая же как и в случае COM...