Уважаемый Andir. Очень проблематично подсказать что-либо в Вашей ситуации, поскольку (это мое субъективное мнение) Вы и сами не вполне отчетливо сознаете, что же в действительности произошло, и суть действий, Вами предпринятых. Короче, полный bcp (Alexanders, наверно, хотел сказать backup).

>"Одним запросом уничтожил базу"
Это что DROP DATABASE? Это значит всю, а не "практически всю". Нельзя немного умереть.

>"Но должны же вестись логи изменений и по-этим логам можно и восстановить"
Резервная копия журнала транзакций не поможет, если нет полного backup'a. Транзакции - это изменения, их надо к чему-то применять.

>"Да, действительно, логи ведутся, причём мегабайтного размера"
Во-первых, мегабайтный размер - это совсем немного, по-видимому, они были почищены незадолго до того, как это случилось. Во-вторых, лог у каждой базы один. Или Вы имеете в виду файлы. А в-третьих, извините, как же они могут у Вас вестись, если база, по Вашим словам, уничтожена. Если Вы подразумеваете master, то с его backup'a Вы в лучшем случае поднимете метаданные, а не контент погибшей базули.

>"То есть восстановить можно только вперёд"
Это чушь. Если Вы имеете в виду процесс recovery, то зафиксированные транзакции действительно накатываются (roll forward), незафиксированные - откатываются (roll back).

>"Полез я тогда уже в физическую среду, т.е. к файлам. Просмотрел логи, саму базу..."
Значит, файлы БД все-таки уцелели? А почему в этом случае не сделать sp_attach?

>"И понял, что восстановить можно! ...вручную : тупо копируя из файлов в базу"
Если это символьные данные, то почему нет? Они лежат там в открытом виде и доступны всем, кто имеет доступ к файлу, если, конечно, Вы его не храните на EFSовской партиции.

>"Базы Всё ещё неустойчивы и в этом направлении надо ещё работать и работать"
Т.е. сделать так, чтобы она неоднократно переспрашивала после команды DROP DATABASE, уверены ли Вы, что хотите это сделать. А сколько бы раз Вас устроило?

>"Расскажите кто-нить о базе TempBd"
Мне кажется, что в сложившихся условиях Вам следует в первую очередь пополнить свои знания по устройству журнала транзакций - http://www.sqlmag.com/Articles/Index.cfm?ArticleID=9792. Я бы также порекомендовал ознакомиться с crash recovery scenarios, вот очень хорошая статья - http://www.sqlmag.com/Articles/Index.cfm?ArticleID=9808. Кроме того, при правильном планировании политики пезервного копирования в Вашей ситуации лучшим выходом стало бы восстановление на момент времени, либо на поименованную транзакцию. После того, как прочтете эти две статьи, гляньте еще вот эту - http://www.osp.ru/win2000/2000/05/062.htm, там есть пара-тройка примеров на этот счет в самом конце.