1с8.2 Управляемые формы. Самописанная конфигурация.
Есть справочник "Работы".
Есть большая таблица значений 2,5 млн записей(группы и элементы).

Задача: загрузить таблицу значений в справочник.

Проблема: Средствами 1с очень долго.

Вопросы:
Какие есть решения проблемы?
Можно ли грузить прямо в СКЛ таблицы? Смотрю ПолучитьСтруктуруХраненияБазыДанных - все понятно. Смотрю на таблицы - не понятно как формируется код ссылки.

как я узнаю нужные?))))

(78) и (79) не подходит

(80) исходя из задачи - где-то в ней закопано то, зачем это все нужно и вот на основании этого "зачем" и можно принять решение, что нужно, а что нет.

выясняю у заказчика...минуту)))

меня поставили перед фактом...пришел аудит такой-то сякой и в такой-то день каталог должен быть в 1с...Щас уточную можно его оставить не в 1с...)))

если заказчик скажет: "мне нужен каждый элемент из этих 2.5млн каждый день 24/7", знай - он врёт. Не бывает людей, которым нужны справочники по 2.5 млн записей.

да это все понятно. Нужно уточнить на сколько жесткие требования. Пока не стала грузить не поняла проблему...

Особенно радует сообщение (28)
" да, но если процедуру выполнять раз в месяц, то хотелось бы все на автомате"
Это получается что каждый месяц вы будете добавлять в справочник по 2 млн записей?Оо

не, обновление данных, там еще цифры есть...

это не щас...главное придумать как загрузить, или не грузить, но использовать откуда-то

заказчик пока молчит...жду...

Смотря что надо.
Если просто информационно и нигде не будет использоваться.
И надо каждый раз очищать и загружать заново, то имхо, в регистр. Хотя всё равно....

нет...точно будет использоваться...

(0) >>Средствами 1с очень долго.
а других в 1С нет.
Про SQL забудьте - в 8-ке он только для сервера 1С, а не для программистов.
Грузите через DBF - очень быстро выгружается и загружается.

Требования жесткие. "Каталог должен быть в 1с!"

(20)1C очень долго читает стандартными средствами текстовые файлы.
Используйте не то, что 1с рекомендует, а ЧтениеТекста.
А лучше - откажитесь от обработки текста в 1С вообще, и  слейте все текстовые файлы где-нибудь на стороне в одну DBF.

(94) ну так и грузите.
Но не средствами "1С:Специалист".

(93) Проблем нет вытащить в 1с. Проблема записать в справочник. Самый простой код ".Записать()" - вот в чем проблема. Написала процедуру записи в справочник. Вот тут и нужно перекопать и увеличить скорость.

(97) на время загрузки изменить процедуру при записи и перед записью в конфе

(97)>>Написала процедуру записи в справочник
тут нет вариантов.
Код платформы закрыт, и, вам остается либо всем восхищаться (как делает большинство) и дальше читать агитки 1С, либо молча "кушать какутус".
Единственно - загрузите частями ("Смотрите, вот он, справочник!"). Ведь никто не будет счиать, сколько там записей - 1 или 2 млн.
А потом подгрузите остальное.

(98) сейчас запустила на тестирование с учетом ОбменДанными.Загрузка = Истина
Жду.

А вот это что за шняга:

           Для Ии=1 по 1000000 цикл
            КонецЦикла;

??

(99)да, мне останется такой вариант

(98) на что изменить? На "запиши все по-быстрому"??
Я уже рекомендовал 1С такую команду в нулевых, 1С только фыркнула в ответ.

(101) можете на эту шнягу не смотреть - это пауза чтобы пользователи могли хоть что-то сделать со справочником работ. Иначе давала ошибки транзакции. Этот код уже закрыла и выгрузку делаю в тестовую.

(101) это тестовый код имитации, если кто не понял.

(104) а как пересекаются справочники Номенклатура и Работ??

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

(106) прошу прощения, что вопросом на вопрос...Я где-то опечаталась и написала Номенклатура?

(106) Грузим в "Работы". "Номенклатура" завязана, но не в этот раз.

(99) Справочник для аудита есть(ночью что-то загрузилось), но задача должна быть выполнена.
1. Загрузить что есть любым путем.
2. Раскрутить скорость и автоматом чтобы каждый месяц.

Попробуй в транзакции записывать хотя бы тысяч по пять или десять элементов.

(100)>> сейчас запустила на тестирование с учетом ОбменДанными.Загрузка = Истина
это на скорость записи не влияет, только на реагирование на ошибки создания и заполнения.

(111) Отказалась от транзакции вообще.
На коде "НачалоТранзакции()" виснет на боевой базе. Кто знает причину?

(112)а что значит на реагирование?

(108)>>Я где-то опечаталась и написала Номенклатура?
>>Это каталоги Ельза по запчастям
Тогда - что за запчасти как "работа"?

(109) 2,5 млн - это два с половиной миллиона работ??

(110)>>2. Раскрутить скорость и автоматом чтобы каждый месяц.
грузите каждую ночь по 100 тыс наименований.

(115) там так и есть...Даны позиции номенклатуры в одном файле, в другом файле нормо-часы, в другом файде модели авто, в другом файле группы, в другом связки....бред...еще полно всего...
Короче в итоге в 1с у меня получаются работы с нормо-часами.

(116) работы и группы работ

(111) >>Попробуй в транзакции записывать хотя бы тысяч по пять или десять элементов.
на скорость записи это тоже не влияет. Лишь на объем занимаемой памяти и вылеты при загрузке.

(120) однозначно транзакции не будет и только ночная загрузка

(118) я бы на DBF все соединил сначала (да хоть через 1С), а потом уже грузил один получившийся кусок.

(112)мысль обдумываю, незнаю результата

(121) "транзакция по 10 тыс" здесь абсолютно ни при чем.
Просто народ не понимает, зачем транзакции в 1С.

как быстро открыть текстовый файл в дбф?

(125) DBF быстро обрабатывается, чтение в 1С ТЕКСТОВОГО файла - весьма трудоемко.
А если еще и по рекомендациям 1С - то вообще конца не увидите.

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

проблема не в чтении текстового

(125) 1. Рекомендую обработать текстовики не в 1С.
2. Если (1 ) невозможно - обрабатывать тектсовики "в фоне", чтобы потом вечерком их автоматом перекидывать в 1С.
3. "В лоб" читать текстовики в 1С, обрабатывать и ждать, когда 1С соизволит все обработать. И при этом не отключится в забытье.

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

(128) с записью - только частями. Постоянно кидать части данных в свободное время сервера.

Некому обработать текстовые. Надо кнопка старта и результат утром.

(130) именно, тут вариантов нет. Либо вы сами разбиваете эти 10 часов на часы, либо - 1С "зависает" на все это время сама.

(132) ну так загрузите все сначала, а потом будете делать поиск по базе и подгрузку отсутствующих данных.

*загрузите сначала весь объем в 2,5 млн записей в 1С.

(0)какую-то ахунею тут понаписали...

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

2.апдейтишь из скуля свой справочник

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

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

(136) вы 1С-ой когда-нибудь занимались?

(136) я человек простой и смысла-то не понимаю написанного

(137)>>структуру типа регистра сведений в 1С
обращу внимание - даже РС не есть единая таблица в SQL.

Я чего-то так думаю... я, наверно, подготовлю внешние готовые битые таблицы с элементами групп. И первоначально подгружу только группы, а потом частями по регламенту остальное...

(141) вам в первом десятке ответов рекомендовали подгрузить сначала только сверхнужные данные. А потом и остальное.

(142) Нужность не поняла сначала

(142) да да, взяла все сказанное на заметку. Спасибо)))...

(138)да. ))) и кстати забыл написать что ссылки следует создавать средствами 1С а реквизиты (включая ссылочного типа) апдейтить скулем

(141) да, да. Делайте именно так, как и написали. И счастье будете тягать мешками.

(141)"готовые битые таблицы " прочел как битовые и крепко думал, прочитал верно и задумался ещё крепче )))

(141)не забудь реквизит синхронизации гарантированно уникальный найти или создать и чтобы поиск по нему адекватно работал т.е. лучше искать запросами чем методами короче

Что можно сделать:

1) Убрать все что делалось при записи и перед записью
2) Посмотреть что все время, на 99% занимает Записать()
3) Убрать из ввода по строке Наименование, Код - это индексированные столбцы, возможно серверу будет проще не поддерживать эти индексы при добавлении элементов - вернуть на место после загрузки, чтобы обсчитал 1 раз.

Больше что-то на ум ничего не идет.

(149)при загрузке нужно проверять существование т.е. искать и не найденные создавать, как будет поиск отрабатывать без индексов? )))

прочел ветку и не понял откуда берется таблица значений(0)

(151) потому что опыть применения других систем хранения в 1С абсолютно неприменим ))
Поэтому я и написал утвердительно - вы не занимаетесь 1С ))
(149) Все, что делает Записать() - это записывает в базу.
Если и есть какие-то "связанные" события, на которые вы намекаете (подписки, ПриЗаписи и т.д.) - это только влияет на ошибки при записи, но не на скорость самой записи "строки" в базу.

(151) Таблица значений формируется в 1с.

(145) создание ссылки в 1С - это и есть создание объекта в базе.
Без объекта - нет ссылки. Точнее, это не будет ссылка, а "мусор", не имеющий никакого значения для базы 1С.

(153) после установки ОбменДанными.Загрузка = Истина получаем не 50%, а 30%.
Поиск групп занимает 18% и запросы 18%

(153) он, как и многие до него "сгоряча", наложил опыт применения "нормальных" СУБД на 1С.
Поэтому и ТЗ у него - это таблица в СУБД уже.

попробую сначала группы все создать и связки хранить в индексированной таблице

(155) чего 30%? При записи или вообще при загрузке?
И потом, после устанровки "обхода" проверок - вы дадите гарантию, что справочники правильно создались, без битой ссылочности, внутренних противоречий (с кодами, другими справочниками и т.д.), и со всеми необходимыми полями?

(155)так показывает замер производительности в цикле процедуры ПеренестиСерверРаботыЕльза

(159) ну т.е. "общего" переноса, а не конкретно при ЭлементСправочника.Записать(), как вы настаивали.
О чем и толкую Вам.

(157)>>и связки хранить в индексированной таблице
это как и где?

вот и думаю и как и где...
таблицу групп хотела грузить сразу, поэтому получить отдельно таблицу значений только для групп, выполнить запись в справочник работ и сразу привязать к ссылкам записи тз.
Где-то сохранить внешними данными...незнаю...значение в строку и положить туда ссылку...Когда запускать регламент открывать эти данные и опять в Тз и проиндексировать и только после этого начинать грузить таблицы элементов...

(162) я ж говорю вам - вы в любом случае упретесь в тормоза/невозможность 1С быстро/правильно/корректно (подчеркните нужное) работать с СУБД при ОГРОМНЫХ объемах данных, начинающихся от 100-200 тыс записей/транзакция.
Я в этом убежден, с чем не согласны большинство здесь на форуме.
Поищите - постоянно пишут о "миллионах обрабатываемых записей" (это, в основном, начальники-руководители и прочая, кто хочет видеть и видит лишь отчеты с агитками), и тут же - либо невозможность (по причине переполнения чего-нибудь - буфера 1С-сервера, памяти, темпового диска, очереди ввода-вывода и т.д.), либо долгие <годы> часы ожидания завершения обработки данных.

(163) так какой выход?

(164) (131 ) + ( 142)
Т.е. анализ данных перед загрузкой - 99% успеха загрузки в 1С.

ну так я этим сейчас и занимаюсь)

(162) не очень большая таблица групп, но чтобы уменьшить время загрузки элементов групп можно сохранить именно готовые ссылки самих групп

(167) вы че-то запутались.
Если эти группы уже есть в базе - вам остается только найти их посиком. Если нет - создавать новые.
Какие еще "ссылки" и на что (и по какой базе) вы собрались сохранять перед загрузкой??

(167) да и это уже не надо)

запуталась, да, уже распуталась)

(168) больше никаких

(170)алгоритм составь и закодь потом под замером производительности смотри как он работает и поймешь как быстрее а (168) с тобой скорее заигрывает чем вопрос решает )))

Вопрос полностью закрыт. Записей оказалось не 2,5 а 11 млн и пришлось отказаться от загрузки в справочник. Придумалась структура из 2 рег сведений и дополнительной обработкой получилась загрузка на час. УРА! Спасибо, что подсказали как быть в случае когда много записей, буду иметь ввиду))).

(172) ну что, только про троллей знаем, и больше ничего? развелось вас немеряно последние года....
(173) вот тут v8: Резко упала производительность 1С ЗУП я отписался именно о записи в справочник миллиона элементов - идет часами.
500 тыс - писало свыше 7 часов (почти 8). Миллион - пишет за 20 часов.
Именно в SQL-варианте.
В файловой DBF все идет совсем по-дургому. это не показатель...

Хранение больших объемов во внешней базе вполне нормальный вариант, почему нет? На прошлой работе в Firebird хранились данные о пластиковых окнах, замерах и т.д., данные формировала другая программа, а 1С читала и модифицировала некоторые поля, причем для пользователя выглядело как обычные справочники и документы

(175)>>причем для пользователя выглядело как обычные справочники и документы
значит, все, что они так видели - хранилось и в 1С.

У кого-то миллион пишет за 14 часов.
Видимо, зависит от мощности серверов и космического излечения.
Но это все - огромные временные периоды, совершенно недопустимые в промышленной БД.

Продолжаем тест.
Поиск среди 1 млн записей: прогонка 100 тыс записей - за 5-6 минут. Молодец SQL, и 1С, что не додумалась хотя б в поиск сунуть свои вездесущие "ноу-хау" (точнее, они есть в Справочник.НайтиПо<...>, но результат производительности, как видим, еще приемлем, - конечно, в критериях работы 1С, - хотя и тут находится на грани разумного).
Запись 1 млн элементов - стала 16 часов. Видимо, SQL "дали возможность" определить "узкие" места, и начал работать SQL оптимизатор - кроме теста, на SQL ничего не запущено.

+ 1С сервер за сутки (пока гонял миллион туда-сюда) понаписал 50 Гб логов.
Так что будьте внимательны - места должно хватать и под логи, иначе вылетит.