K C++ вопрос не относится, вообще-то. Это ближе к проектированию систем и администрированию баз данных.

В общем случае миграция делается так:
- Читаешь строку из исходной таблицы.
- Проверяешь на правильность данных.
- Если нашел кривые данные - пытаешься догадаться что оператор имел в виду когда печатал чушь. Например если ты знаешь что работаешь с датой рождения и видишь человека родившегося в 2070-ом году - догадываешься что это должен быть 1970 и исправляешь.
- Если исправить не получается - либо обнуляешь кривые данные, либо сбрасываешь в какое-то специальное значение, либо убиваешь строку (или весь логический объект) целиком.
- Не забывай записывать все случаи исправлений-убиваний записывать в журнал. Потом читай его и ищи где можно улучшить процедуру исправления кривых данных. После нескольких прогонов получишь конфетку.

И все...

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

MasterZivЗагрузка в БД во временное хранилище оправдано только, если другими способами как в БД (используя естественно SQL или PL SQL)
данные не обработать. А так -- это напрасная трата времени и ресурсов.Не знаю при каких условиях данные нельзя почистить на клиенте.
Вот как раз временные хранилища в БД я назову напрасной тратой времени и ресурсов.

sherzod_,
Замечание о потоках верно, все остальное не верно.
Ни блочные заливки, ни "штатные средства" ему не помогут. Первое умрет на этапе кривых данных (прочитай первый пост топика). А "штатные средства" либо тоже умрут на кривых данных, либо потребуют не малых денег, а потом еще и не малого времени на настройку.

denis_stell,
Мне сильно кажется что ты занимаешься переливкой данных. Читаешь из одной таблицы и пишешь в другую. Так? Если "да", то очень плохо.
Сделай на клиенте структуры (классы) представляющие собой бизнес-объекты. Потом заполняешь эти объекты из одной базы, и после того как собрал объект целиком - пишешь в новую базу. Простой цикл в один поток. Просто, легко и надежно.
Этот подход даст тебе намного более удобный для дальнейшей работы лог ошибок. Сможешь писать туда что-нибудь в духе: "Клиент ФЫВА имеет плохую дату в дне рождения. Клиент ЯЧСМ имеет три контракта в списке контрактов, но найдено только два контракта найдено в реальности". Потом отдаешь этот список начальству и тем кто вбивает данные в старую базу - они исправляют данные.
Заодно сможешь с легкостью изменить структуру хранения данных в новой БД.
У меня подобные схемы работали (и работают) очень даже замечательно.
А по скорости работы зависит от объема исходной базы и драйверов доступа к базам. Когда-то, на заре века, у меня двухгиговая DBF база превращалась таким образом в ASA7 за два часа. Сегодня 50Г данных переливаются из MS SQL 2008 в ASE 15 за час. В обоих случаях программы-превращатели написаны на С.

sherzod_White Owl,

о чем это вы. Это стандартная ДБА задача. Какие еще программы на компилируемых языках. Люди на TransactSQL биллинги целые пишут, включая работу с устройствами, файлами и со всем остальным, а вы говорите на плохих данных ляжет ).Это далеко не стандартная задача и уж совсем не для DBA. Это задача для дата-архитектора, а не администратора сервера.

sherzod_ Ровно один запрос на каждую таблицу, независимо от того что там с данными, ровно два запроса при использовании bulk insert.Вот это и есть твоя ошибка. Ты не смотришь на то "что там с данными". Да, в идеальном мире, источником данных будет идеальная база с идеальной целостностью данных. Тогда действительно данные типа "имя" или данные типа "адрес" можно получить разом по всем контрагентам за один запрос. Но в реальности, мы вынуждены жить с базами в которых бывают контрагенты без имени и имена без контрагентов.
А так же, задача миграции с одной базы на другую всегда сопровождается сменой структуры базы. Раньше имя хранилось так, а теперь имя будет хранится сяк. Раньше накладные хранились в двух таблицах, а сейчас будут в двадцати-двух. Смену структуры хранения ты в конечно в несколько запросов упихать сможешь, но bulk insert обломается.

sherzod_ При том что править их в десятки раз быстрее, поправил-попробовал, поправил-попробовал. А тут компилируй, подключись, запусти, посмотри, ищи ошибку. Смех да и только.Смейся. Когда сам попробуешь позаниматься мигрированием БД - будешь смеяться еще раз.