Как получить данные 1С непоследственно из dbf файлов #18638

Необходима синхронизация данных 1С и другой БД (Delphy).Получение данных из 1С (OLE) за месяц занимает 3,5 часа. Всего 950 документов по 10 - 20 строк.Очень долго.Было бы быстрее скопировать нужные dbf файлы и запросом получить то что нужно. Но как?Кто нибудь делал что-то подобное?

1С-ка хранит в dbf-ках информацию не совсем пригодную для непосредственной работы. Лучше выгрузить из 1С-ки обработкой то что нужно. А потом тащить из них то что нужно. Процедура не сложная. См. описание встроенного языка

А точно OLE виновато, может запрос не оптимизирован? Попробуй одн и тот же алгоритм при формировании файла импорта через OLE, и напрямую из 1С. С OLE работаю нечасто так что сказанно мной не аксиома, меня всегда устраивало скорость через OLE.

Пригодна или нет - это дело вкуса. Пока нет времени вникнуть, но кажется, что все данные можно получить анализируя файлы DD и MD.. сначала пытался получить значение табличной части документов за месяц запросом. И обработкой и OLE, но запрс выполнялся очень долго. Прождал 1 час и снял задачу.

Какие данные можно получить из MD и DD? Только структуру метаданных и код. А тебе нужна структура dbf-ок с данными.* * *Еще раз скажу - не стоит работать со служебными dbf-ками. Лучше из 1С-ки выгрузить только то что нужно в специально созданную dbf-ку.* * *Что-то не так с запросом если он данные за месяц не может получить за час. Покажи код запроса, разберемся

1 описание языка работа с дбф(все довольно шустро)2 в .dd есть описание всех dbf и полей бери и пользуй

Да не нужно работать с 1С на физическом уровне. Она сама способна достаточно быстро все выгрузить, и не придется выполнять ту работу которую хорошо выполняет платформа

Выложи текст запроса и при обработке запроса обращаешься к базе данных или пользуешься результатами запроса. Обычно еще существует такая фишка, что идет перебор документов, хотя, ИМХО, стоило перебирать движения регистра, порожденные этими документами.

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

Первоначальный текст запроса не сохранился. Опишу по памяти.3 группировки - реквизит шапки12 группировок - реквизиты ТЧЕсли реквизит - элемент справочника - получаю код (через OLE трудно с объектами работать)Всего должно выгрузится порядка 35000 строк. Так что не удивительно, что такое большое время.Сейчас делаю перебор документов. Так лучше видно процесс. Раньше прога уйдет на выполнение запроса и не понятно висит или что-то делает. МОНОПОЛКА не годится - синхронизация параллельно с работой других юзеров.

не понял у тебя синхрон в текущем времени что-ли

Да. Просто одна БД ведущая, другая ведомая (в некоторой области данных).

и на каких русурсах ты это тянешь?

М-да. Понимаешь, даже запросом при проверке условий постоянно обращаться к базе, да еще после выполнения обрабатывать запрос и опять лезть в базу за недостающим, хотя лучше было бы все это включить в запрос. Но нужен был текст, а не твои намерения каким должен быть его результат.

раз в ночь это делать нереал?1с туеву хучу времмени тратит на проверку доступаиз практики в моно бывает 7-8 раз быстрее

Пока отлаживаю программу на VB6 на локалке (1С на серваке). Позже обещают выделить отдельный комп. Пробовал запускать на принтерном серваке - тормозит печать.Речь не идет о мгновенной синхронизации. Но хотелось бы уложиться в 1 час. НО пока приходится планировать только ночную обработку :)

> Если ты хорошо помнишь, что такое Primary key и Foreign key, а также хорошо разобрался, как в 1с реализованы 3УНФ и 5НФ, то может есть смысл начать составлять таблицу отношений твоей БД. Если у тебя получится сделать это без ошибок, то останется с какой-нибудь быстрой СУБД для dBase (например Visual FoxPro или СА Visual Objects) написать все, что тебе нужно. Но, я думаю, обработка с использованием OLE сделает все горазда раньше, чем ты проделаешь все перечисленное. Удачи:)

Ничего не понимаю...Самый быстрый способ - как раз напрямую из ДБФ-ов базы вытаскивать данные.Структура - очень простая - какие там могут быть проблемы?

Дело тебе говорят.Не заморачивайся.Запускай свой прогой 1С под юзером, который автоматом делает выгрузку во внешний файл нужной тебе структуры и выходит из 1С.После этого уже грузи прогой это файл.И прозрачно и быстро и красиво и самое главное легко модернизируется в дальнейшем.

Вот и я о том-же. Конечно в начале придется повозиться.Пробовал просмотреть dbf файлы. И видет те данные (не все пока), которые нужны. Получить по запросу подключив dbf к mdb - (мне кажется) можно за несколько секунд. По крайней мере из БД Delphy я получаю данные так (подключив файлы db).Но проблема в том, что структура и имена в 1С формируется динамически. А у меня еще 2 филиала и нет гарантии что имена файлов и полей везде одинакова.Хотя модет и это и не так...

Текст запроса (здесь только нет периода):ОбрабатыватьДокументы все;Обрабатывать НеПомеченныеНаУдаление;Группировка Doc;Группировка Predpr Без Групп;Группировка Agent;Группировка DateP;Группировка NumG;Группировка Ga;Группировка Gor;Группировка Zak;Группировка Nar;Группировка Tip;Группировка Ru;Группировка Kol;Группировка CenaFirst;Группировка Cena;Группировка CenaIno;******** Я уже пробовал получить данные запросом, но обработка более 1 часа.Даже если запускал этот запрос из внешней обработки (ert).

Выгрузи все.Надыбай ВК, которая сохраняет ТЗ в DBF.Своей прогой потом группируй.P.S. И слушайся старших.

Если убрать группировки, то ни чего не получим..На счет ВК стоит подумать. Но опыта 0. И будет ли ВК быстрее работать чем обычная обработка (процедура в 1С)?

Как это ничего? Проверял ;-)Запрос.Выгрузить(ТЗ);ТЗ.ВыбратьСтроку;Проверь, ка.---ВК нужна (ли) только для выгрузки ТЗ в DBF.Можно и без нее обойтись. Но ты же хочешь быстрее.

Я о запросе...Если в запросе нет группировок (а формул и условий у меня и так нет), то получим пустой запрос.Как потом с данными запроса поступить - нет проблем. НО сам запрос выполняется больше часа!Вот где собака порылась (с) Горбачев.

|Группировка Док Без Групп ;-)

и

(25, 26) Согласен, но это не ускорит в разы. По большому счету нет разницы будет ли формироваться запрос 2 ч 10 м или 1 ч 50 м. Все таки непосредственное получение из dbf - самое быстрое.Просто хотел найти единомышленников. И может кто-то поделится своим опытом. Но видимо не судьба...

ну, если проверять лень - то ...

А чего там делиться?Отчет-то простой, как и любая загрузка из ДБФ-ов

Проверю. Но позже. Я о том, что бы получить данные из dbf файлов самой 1С, а не сформированного обработкой или еще как-то.

А что, у 1С какой-то особенный ДБФ?Формат ДБФ-1С-ТМ?

И еще один момент. Как было замечено выше - особенного смысле делать перебор по документам нет. Ведь представляют интерес бухгалтерские и оперативные итоги которые эти документы формируют. Значит проще и быстрее сделать запрос например по регистрам.* * *Вот это действительно ускорит процесс в разы

Да нет же. Просто имя таблицы и имя поля 1С формирует самостоятельно и я не уверен, что запрос будет работать на всх БД 1С (в филиалах). Поэтому придется создавать запрос на основе анализа MD и DD. А это не просто (ИМХО). Как раз регистры меня не волнуют. Необходима инфа ТЧ. А итоги это бухам. Мне важно что бы первичная информация перетекала автоматом.

Обращаю внимание на то что именно из регистров (ну или из бух итогов) возможно самым быстрым образом получить информацию о документах породивших движения нужного вида.* * *

Перебирать же первичную информацию (документы) нет никакого смысла. Нужно знать принципы работы платформы чтобы не делать таких ошибок

А вот это МЫСЛЬ. Если хорошо сделать движения регистров, то все можно получить и там. Есть о чем подумать.*****Итак выводы:1. Попробовать оптимизировать запрос (немного побыстрее будет)2. Получать инфу из регистров.Докумет добавляю новый и регистры еще не прописывал. Видимо из-за этого и зашел не с того конца :).Всем спасибо.