Тормозит Экспорт/Импорт данных

[Wamr]

Простите, можно уточнить что означает фраза?
"С Oracle такой фокус не проходит, поскольку длинные имена таблиц и полей отличаются в наименовании по физической структуре представления БД сервером"

[st_msav]

Цитата:

Сообщение от Wamr

Простите, можно уточнить что означает фраза?
"С Oracle такой фокус не проходит, поскольку длинные имена таблиц и полей отличаются в наименовании по физической структуре представления БД сервером"

Скажем в Аксапте есть таблица LongNameTable в структуре БД SQL Servera ее имя уже выглядит LongNameT8012. В представлении БД Оракла эта таблица называется так, как в Аксапте. Та же песня с длинными полями.

[db]

Цитата:

Сообщение от st_msav

Скажем в Аксапте есть таблица LongNameTable в структуре БД SQL Servera ее имя уже выглядит LongNameT8012. В представлении БД Оракла эта таблица называется так, как в Аксапте. Та же песня с длинными полями.

16 ГБ стандартным экпортом-импортом? Хотите умереть на работе? Ну ну

соответствие аксаптовских и бд-шных имен живет в SQLDictionray
Возьмите эту таблицу и из Оракла и из SQL, постройте на их основе таблицу для соответствий имен
Axapata-Оракл-SQL и поместите, например в SQL-базу

Прилинкуйте Оракловый сервер к SQL-ному
С использованием таблицы соответсвий нагенерите скрипт из команд типа insert into oracle select from sql, не забыв при этом
перекодировать все пустые sql строки в chr(2)

Исполните скрипт - при нормальном железе база перельется часов за 6.
Не забудьте перенести системную табличку SystemSequences

[mazzy]

Цитата:

Сообщение от db

С использованием таблицы соответсвий нагенерите скрипт из команд типа insert into oracle select from sql, не забыв при этом
перекодировать все пустые sql строки в chr(2)

Исполните скрипт - при нормальном железе база перельется часов за 6.
Не забудьте перенести системную табличку SystemSequences

Угу. Вы уже выполняли подобную работу?
Каковы результаты?

Еще немножко побрюзжу:
1. Типичный программистский подход - вместо решения основной проблемы решать кучу маленьких вспомогательных технических проблем (с основной никак не связанных). Еще раз: основная проблема медленной работы - поиск связанных RecID.
2. Что самое показательное, не говорится, что перечислены все пункты, которые надо "не забыть"
3. И никто не гарантирует, что получится правильный результат
4. Когда я слышу подобные рассуждения от программистов, то отношусь обычно очень подозрительно.

db, надеюсь, вы знаете, что советуете.

[db]

Выполнял, замечательные, 75 ГБ за 8 часов, база функционально один в один и никаких проблем

1. Да, типичный программерский подход - не брюзжать, а сделать дело - перевести клиента на другую СУБД за полночи, не забыв поспать самому
2. Перечислены
3. Как хотите, господа консультанты

[Vadik]

Цитата:

Сообщение от db

2. Перечислены

а SQLSYSTEMVARIABLES тоже переливаете "1 к 1" ?

З.Ы, Все, понял - не переливаете, ее в SQLDICTIONARY нет

[komar]

Цитата:

Сообщение от db

Выполнял, замечательные, 75 ГБ за 8 часов, база функционально один в один и никаких проблем

1. Да, типичный программерский подход - не брюзжать, а сделать дело - перевести клиента на другую СУБД за полночи, не забыв поспать самому
2. Перечислены
3. Как хотите, господа консультанты

Может, Вы поможете участникам, и выложите на всеобщее обозрение свой скрипт, тем самым подтвердив свою точку зрения?
Я, например, также считаю, что стандартным импортом 16 Гб качать нереально долго, хоть бей на блоки, хоть не бей.

[mazzy]

Цитата:

Сообщение от db

Выполнял, замечательные, 75 ГБ за 8 часов, база функционально один в один и никаких проблем

Ок. Спасибо.