Быстрая загрузка данных из базы SQL #721360

Добрый день, всем. Есть такая задачка. Имеется база SQL. К ней я делаю запрос и получаю данные. Далее эти данные помещаю с таблица значений, таблицу значений передаю как параметр в запрос 1совский и дальше с ней работаю. Дак вот табличка с данными стала ну уж очень большой, и уходит порядка получаса для того, что бы прямым перебором ее запихать в таблицу значений. Есть ли как-нибудь другой способ? Внешний источник данных пробовал. Ничего хорошего.

Временные таблицы? Не, не слышол

а напрямую запросить? подозреваю, будет то же, что и с внешним источником

большая это сколько?

[Есть ли как-нибудь другой способ] засунуть напрямки в табличку 1С на сиквеле

примерно так: Вставка = "бла-бла первый запрос" Второй запрос = "......"+ Вставка + "....."

* "вставку" вставь там, куда ТЗ свою сувал. это по-простому

хм.... А дайте код создание временной таблицы в скуле, чтобы к ней потом запросом 1с можно было обратиться.... И да, код вытяжки покажи....

Вот как бы из скуля по временную таблицу 1ски сделать. хочу знать 4 миллиона записей сейчас и прогнозируется рост Не понял Тут все наверное стандартно     Если НЕ RecordSet.EOF Тогда

измени вот эту строку RecordSet.Fields(RecordSet.Fields.Item(НомерКолонки).Name).Value; перед циклом получай все элементы Fields в переменные. Намного быстрее будет.

Не понял как этот должно выглядеть

Как-то так получилось. Вроде работает     Для НомерКолонки = 0 По RecordSet.Fields.Count-1 Цикл Вечером посмотрим прирост в скорости. Есть еще какие-нибудь варианты ускорения?

Посмотри на GameWithFire. Дальше некуда.

Эти 4 млн. строк в SQL часто обновляются? Если нет, то я бы тащил только новые и добавлял их в рег.сведений в базе 1С. Можно делать такое обновление РС в фоновом режиме. А запрос по РС строить.

В таблицу SQL с нужным индексом... или в какой-то служебный регистр сведений

читайте про метод ado getrows   если 1с - клиент- серверная , то можно в таблицы бд 1с (РС)записать обработать, затем очистить можно ускорить чтение данных из скл если написать clr-метод который превратит выборку в тз спрятанную в хранилище Значений

Что ты потом с этими данными делаешь в 1С-ом запросе?

BULK INSERT?

Собственно так и делаю. Получаю данные раз в день, пишу только изменения в регистр, а пользователи уже с регистром работают. Задание стало работать 40 минут. Из них 30 получение данных. Пока еще все терпимо, доводить нетерпимо не хочется.

Не совсем понятно. Если получение данных сделать заранее - то останется только отчет построить, т.е. 10 сек.

Храни в приемнике дату актуальности таблицы, а из источника получай только записи, которые актуальнее даты актуальности приемника. Ну, это прокатит, если во внешнем источнике есть timastamp

* timestamp

с getrows вот такой косяк. Ошибка при вызове метода контекста (GetRows)     COMSafeArray = RecordSet.GetRows; по причине: Произошла исключительная ситуация (Provider): Недостаточно памяти для завершения операции на TOP 1000 очень шустро отработала, а вот на полной таблице не взлетело

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

Не понял зачем здесь вообще ТЗ и запрос в 1С

Хотя бы для того что бы в регистр сведений записать ссылку на номенклатуру, а не ее код, который мне отдает сторонняя база SQL. Плюс дублирующие записи отсечь.

Можно в SQL повесить триггеры, которые в отдельную таблицу будут добавлять измененные строки, и там всё что угодно можно замутить.

Так что с внешним источником ? Получив оный джойните с чем хотите и не надо никуда перезаливать. Джойнить получится токма в СКД.

4 000 000  это не объем.

в принципе они и были придуманы (источники) для этих целей - для соединения (объеденения ) в единой среде выполнения

При тесте внешнего источника памяти сожрал процесс 2 гига и помер.

Поля поиндексируйте в таблице внешней . может и взлетит.

Ставьте топ 100 при тестах.

Пробовал. Та же история

Первый запуск на TOP 1000 делаю. Если все взлетает, то беру целиком.

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

Сравнения в цикле делаются медленные чем в запросе. А скулявая база не держит срез последний 1совский.

есть у тебя таблица №1: <ID> <Данные> Создай в SQL-ной базе таблицу №2: <ID>. Когда получаешь данные, получай из таблицы №1, за исключением данных в таблице №2. Когда в 1С обработаешь записи, пиши в таблицу №2 <ID>. <ID> - одно или комбинация полей.

Со структурой в скульной базе можно конечно попробовать оптимизец навести. Но данных все равно много будет. Так что начальная задачка остается.

Делай обмен чаще.

Чаще плохо. Посчитать не по конечным данным юзеры могут.

Соединение в запросе, а не сравнение в цикле Все там моментально будет если применить моск

может есть возможность сразу готовые данные получать из SQL? либо часть данных из 1С помещать в ВТ SQL, а потом уже тянуть запросом результат?

Можно поиграться признаком Активность записи РС.

А частями грузить, по миллиону записей допустим?

Из 4 млн. считаных записей, сколько пишутся в регистр?

вангую "500 штук" и проблема добавить в запрос вхере Выражение

70% примерно. Частями получать тоже можно. Даже реализовано.

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

Вот наверное по такому пути я и пойду.

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

так что там с клавиатурой то решилось??

Без понятия

Переделка из ускорила примерно в 2 раз.

избавьтесь от RecordSet.Fields.Count-1 и будет еще быстрей если будете в getrows  получать не все данные а порциями (например по 50000 записей ) будет еще быстрей.

55+