Предполагаю устраиваться на работу в контору, где первым заданием будет перенос данных из ТиС 7.7 в УТ 8.1. Кажется, они планируют это сделать с помощью "Конвертации данных".
Контора занимается торговлей запчастями для авто, так что, ИМХО, справочник "Номенклатура" может содержать сотни тысяч позиций. И думается мне, что тысяче так на 10-ой обработка скажет: "Не могу прочитать XML" и усё.

Вопрос звучит так: подходит ли "Конвертация данных" для переброски справочников > 100.000 элементов.

(0) будет крошечный файл на пару Гб

(1) гораздо скромнее

(2) возможно, важно то, что угрозы со стороны объема данных нет

(3) а если "затык" на середине операции, то все сначала повторять?

(0)Не потянет-выгружай по частям. В чём проблема-то?

Я бы взял частями, но мне нужно сразу... (С)Бендер О.И.

(4) не того боишься
под запчасти ТиС в дым переписан
в УТ 11 много нет

снаписанное под себя перенос будет работать на порядок быстрее и менее ржачно...

(8) я думал на эту тему: можно написать обработку с автоматическим поиском оптимального количества операций в транзакции.

(9) лишняя работа,
если типовые правила ТиС->УТ 10.3 не подойдут, то писать придётся много больше тривиального справочника номенклатуры

кстати единиц измерений будет много больше

Как два пальца об асфальт.

100 тыщ номенклатуры это даже очень мало.

только долго будет, если база большая.

а СОМ чем не нравится? - там такой проблемы точно не будет

(14)будут другие)

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

(16) Он вроде бы не продает решения. Да и процедура разовая. К тому же покажи каким ЛС запрещено данные напрямую таскать из 7-ки?
Т.е. были потуги для 8-ки, но не для 7-ки

(17)а что, структура 7.7 хранения данных уже опубликована для всех и вся официально?-=)

(18) она опубликована для каждого пользователя 77. Причём вполне официально

(19)значит я что то пропустил в этом мире.
Тогда можно не стесняться и тащить напрямую

(18) А что файл dd зашифрован или запрещено его смотреть?

(21)были некоторые сомнения по второму вопросу.
собственно, они и сейчас есть, но я лучше спрошу у тех кто точно знает

смотреть - одно, использовать для доступа к БД различные механизмы - другое

(23) ссылку для 7-ки где запрещено

(24)отъипись)
я ж выше написал, сам не знаю

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

для обмена лучше КД вообще ничего не придумано.

(14) Повеселил.

Адназначно. Разделить можно все.

(21) У него может быть dds, а может ты не знал.

(26) у какого чпшника?)) я в понедельник только иду на собеседование в контору средней крупности, к которому (собеседованию) хочу подготовиться. Будем смотреть подойду ли им я, подойдут ли они мне :)
Первая задача там будет упомянутый перенос данных. Интересуюсь именно возможностями КД.

Если делать самописку, то, ИМХО, самый быстрый способ ЭКСПОРТА данных из 7.7  это прямой запрос (1С++) с директивой "for xml". При это медленный механизм клюшек не задействуется, работает только SQL-server. XML-ку на 100.000 элементов он выплюнет меньше, чем за минуту.
Но дело в том, что при переносе данных экспорт это, ИМХО, 10% работы, а импорт - оставшиеся 90%.

(31) у тебя как хватит времени скачать типовые правила перехода ТиС-УТ 10.3
открыть их в КД, изучить и протестировать

(32) ну это же не на тестовом задании. а при собеседовании только можно концепцию изложить :)

> Первая задача там будет упомянутый перенос данных.
А не крутовато ли для тестового задания?

>самый быстрый способ ЭКСПОРТА данных из 7.7
Зачем быстрота выгрузки в разовом переносе? Да и весь импорт руками писать.

А по объемам - небольшая розничная продуктовая сетка в десяток магазинов самообслуживания - около 30000 позиций за три года (это всего, а не на остатках). 100000 - это реально, но для весьма и весьма крупного магазина, но скорее для торговой сети.

номенклатура фигня
давеча ковырялся: типовые правила ТиС - УТ валятся в нехватает памяти даже на небольшой базе, если при переносе доков поставить галку "переносить партии".
А так вроде бы работают вполне...

mdocs
нет, брат, тестовое задание будет какое-то другое. перенос данных - это то, чем придется заниматься в первую очередь при согласии сторон.
а контора вот
http://www.rain-auto.ru/
мне кажется, там может быть и поболее 100.000

частями перенеси на определенную дату?

(37) Эт вряд ли. В каталоге на сайте 20000 позиций, скорее всего как раз вытащенных из 1с. Ну да ладно - это мелочи. А так да, на худой конец чуть допилить выгрузку и частями выгружать.

(37) http://hh.ru/vacancy/4596460
тебя ждёт связка УТ - УПП
так что 120 000 - разумная  оценка

(38) брат, я не знаю. но вопрос очень хороший!!! одно дело РАЗОВО перенести данные и проверить соответствие баз с помощью отчетов. но, ИМХО, грамотнее перенести данные и пока сотрудникам привычнее работать в старой базе, добавить регулярную синхронизацию старой базы и новой. И смотреть, как данные идут в новую базу. Если бы я был Директором, меня бы только такой вариант переноса данных и устроил.

(41) хз.. во тработа в двух базах, да еще и контроль за синхронизацией - вот это адский гемор..

обычно все вменяемые "переходы"делаются так: с такого то числа вот эта база рабочая а вот эта архивная.. и все.. не жужжим..

(40) вакансию вычислил верно) правда, как я пока понимаю, УПП там ни каким боком, иначе я бы отказался. Ну не знаком я с УПП.

(42) я делал контроль за синхронизацией на практике.
для этого завел в Приемнике дополнительный регистр сведений и при импорте проверку: это новый объект или существующий.

(43) прояви инициативу
задай вопрос о все системе
где то же есть и баланс и бюджетирование

(45) проявлю. тем более бюджетирование знаю на практике. и на собеседовании правильнее задать 10 грамотных вопросов, чем дать 10 ответов.