Я как то макетировал подобную ситуацию, судя по результатам и по документации, при присоединении базы без журнала,обязательно выскакивает эта ошибка, но журнал создаётся, правда в заданном по умолчанию расположении на диске.
Встречный вопрос. А Вы читали в рассылке:
Уловка, позволяющая обойти критическое (Emergency) состояние базы данных и особенности DUMP TRANSACTION WITH NO_LOG

Вы перетаскиваете только пользовательские базы или ещё и системные?
Для системных есть маленькие нюансы.

Есть предложение, кинте мне своё мыло, я вам перешлю статью из завтрашнего номера рассылки (как раз на эту тему), может быть она поможет.

Так наверное будет быстрее, вот тут макет следующего выпуска рассылки:
http://www.sql.ru/subscribe/053.shtml

Suspect - это плохо пахнет... Что то у Вас не так. Какой у Вас размер базы и её журнала? Были ли аппаратные ошибки в системном журнале ошибок NT и её журнале ошибок приложений? У железа, которое дисковой подсистемой рулит, свежие драйвера? Тут много чего может привести к подобной катасторфе

А размер базы какой? Если в перспективе он не превысит 9,1 GB, я бы зазеркалил на RAID два SCSI диска и базу положил туда. На счёт RAID для UltraATA100, ничего не могу сказать, не пробовал... Хотя, по идее, можно на 4-х дисках поднять 5-й RAID, котороый разбить на два логических диска, один под систему, а второй под журналы. Если же 9-ти Гб недостаточно, то придётся ложить данные на IDE диски, что я, обычно, старался избегать. Возможен также вариант организации на IDE RAID контроллере двух зеркал.
Кроме того, критично сколько пользователей работает с базой. Если много (высокая утилизация железа и I/O), а база больше 9-ти ГБ, то памяти для эффективного кеширования может оказаться недостаточно. В рассылке предлагались методы выяснения загруженности системы и сервера, а также варианты масштабирования.