segun Yuri AbeleА SQL Server Migration Assistant for Oracle (SSMA) гонял кто-нибудь?да, хороший и перспективный инструмент, позволяет сэкономить массу времени. Вот статья - Microsoft SQL Server Migration Assistant
Да уж - особенно радует конвертация ХП с PL/SQL на TSQL одним щелчком. Как человек, писавший конвертор БД MSSQL 2000 на ASA9, как раз с полным переносом схем и процедурных обьектов, могу смело заявить, что лажа все это - полный конверт возможен только при условии, что destanation по возможностям похож или имеет больше функиональности, способной эмулировать расхождения по отношению к source серверу БД. ASA9 имеет больше возможностей, поэтому мой конвертор этак на 90% перегоняет БД из TSQL на WatcomSQL, не конвертя фактически только архитектурные особенности MSSQL (БД Master и TempDB, серию специфичных системных ХП и функций и т.д.), но занося их факт использования в коде в логи для ручного исправления. Однако как можно впихнуть PL/SQL на TSQL, который Microsoft не очень то удосужилась догнать до уровня процедурных языков конкурирующих СУБД, делая ставки на C#, очень плохо себе представляю (я уж молчу про светлые надежды замены сиквенсетов инкриментами, псевдо-поле ROWID и многие ограничения MSSQL, которых просто нет в Oracle).

P.S. Кстати насколько я понимаю MS сделала ход конем - если народ на MSSQL2005 начнет в ходе работ использовать C# процедуры, то перевод БД на другой сервер будет крайне затруднителен (тут уж и я конвертор написать не смогу). Так что не знаю как насчет прибавления функциональности, а вот защиты от перевода на конкурирующие БД они добились

segunА вы скачивали и смотрели этот продукт или просто прочитали статью и сделали выводы?
А смысл скачивать ? Что - сей продукт "волшебным" образом расширяет функционал TSQL до уровня PL/SQL ? По моему достаточно здравого логического рассуждения, чтобы понять, что это лажа. Привожу простой пример - в статье написано, что генераторы Оракла автоматически заменяются счетчиками. Сразу видны несоотвествия:
1. Генератор Оракла может использоваться как сквозная нумерация на несколько таблиц. Счетчики MSSQL этого сделать не в состоянии. В отличие мухлежа с ROW_ID, счетчики в таблицу-эмулятор с структурой "name, value" не вынесешь, так как она будет по любому участвовать в транзакции.
2. Никто не ущемляет Oracle программистов использовать несколько генераторов на таблицу - как известно два счетчика на одну таблицу не повесишь.
3. Генераторы могут использоваться в любом месте - триггере (BEFORE кстати), хранимых процедурах и функциях PL/SQL и клиентской части, причем код может получить как текущее значение генератора, так и потребовать следующее. В MSSQL2000 можно получить только текущее значение счетчика, буду рад узнать, что в MSSQL2005 сделали аналог ASA-шной функции GET_IDENTITY(), позволяющей получить по указанной таблице новое значение счетчика без физической вставки записи - только тогда можно эмулировать поведение генераторов через счетчики.

Не спорю, конечно они могли и выкрутиться: например организовать на каждый генератор табличку с инкрементным полем и написать дублирующие функции генератора, которые считывают последнее значение счетчика и заносят туда новую запись, возвращая полученный @@IDENTITY. Только вот записи в ней добавлятся будут - как никак участвует в транзакциях, если не сделали аналога GET_IDENTITY().

Но все это цветочки - а вот как быть с наворотами Оракла, в виде ООП, массивов, динамического SQL с поддержкой выполнения скрипта большого объема и прочих радостей жизни ? Неужели тоже эмулировали ? Будет интересно услышать отзывы и впечатления тех, кто воспользовался этой утилитой для портирования полноценных промышленных БД Оракла на MSSQL2005, а не мелких базок, написанных студентами. Я конечно не знаток Oracle, однако так как имел опыт написания конвертора с MSSQL2000 на ASA9, которая на достаточно большом уровне поддерживает максимальную совместимость с ним (насколько позволяют собственные архитектурные особенности) ... и то не мало подолбался, пока написал полноценный конвертор. И ведь это я писал для связки, где ASA9 значительно на уровне WatcomSQL превосходит TSQL и позволяет полностью на своей функциональности эмулировать особенности TSQL, которые в ASA в явном семантическом виде отсутствуют и реализованы по другому. Однако даже с учетом нового, появившегося в MSSQL2005 я лично себе не представляю написания обратного конвертора БД с WatcomSQL на TSQL 2005, несмотря на расширения, отсутствует целая куча необходимой даже для эмуляции функциональности. Что же тогда говорить об миграции с Oracle, где много народу просто обожает пользоваться курсорами, массивами и прочей с моей точки зрения несуразностью по старинке, хотя вроде бы как 9-ка и 10-ка по функционалу SQL уже позволяют счастливо избегать таких вредных привычек ?

segunИ Oracle и DB2 в той или иной степени поддерживают интеграцию с .Net.
Та же песня - в той или иной степени - это обычные расширенные хранимые процедуры, как например это сделано в Oracle, DB2 и всех Sybase серверах для поддержки Java. Насколько я понимаю, в MSSQL2005 сделана довольно тесная интеграция с .NET, позволяющая много чего, что не сможет обычная расширенная хранимая процедура или функция. Или я ошибаюсь ?

ChA ASCRUSЧто же тогда говорить об миграции с Oracle, где много народу просто обожает пользоваться курсорами, массивами и прочей с моей точки зрения несуразностью по старинке, хотя вроде бы как 9-ка и 10-ка по функционалу SQL уже позволяют счастливо избегать таких вредных привычек ?
Есть подозрение, что Вас скоро будут бить :)) Возможно, начнут уже сегодня...
С какой стороны - Oracle или MSSQL ? ;)

авторну.... насчет GET_IDENTITY() - можно получить текущее значение и приращение через набор функций ident_current/ident_seed/ident_incr
Перечисленные функции не возвращают новое значение в MSSQL2000. Только последнее - в этом есть разница и кстати иногда большая и обидная.