Vista 64 ビット上の SQL Server 2008 Developer Edition の場合:
アタッチ/デタッチ メソッドを使用して Vista 管理者アカウントを使用してデータベースをコピーしようとしましたが、ファイルのアクセス許可エラーが原因で失敗したため、SQL サービスがディレクトリへの書き込みおよび変更として実行されていることをユーザーに伝えました。コピーはうまくいきませんでした。それから私はそれを完全に制御しました。コピーは機能しました。
それは理にかなっていますか？
ユーザーからフル コントロールを取り消すと、問題が発生しますか?
奇妙なことに、別のディレクトリにファイルがある既存の作業データベースでは、データベースのディレクトリとファイルに特別なアクセス許可がないのに、なぜコピーに完全な制御が必要なのですか?
DB をデタッチすると、MDF/LDF ファイルは、デタッチを実行したプリンシパル (デタッチを実行したユーザーの SQL Server サービス アカウントまたはドメイン アカウント) に限定されるなど、予想よりも制限された権限で設定される場合があります。過去に、ファイルの [プロパティ] > [セキュリティ] タブで、他のユーザーのアクセス許可を手動で追加する必要がありました。そうしないと、ファイルがロックされているかのように動作します。http://www.onupdatecascade.com/2009/07/sql-server-locks-mdf-and-ldf-files-upon.htmlも参照してください。
また: http://msdn.microsoft.com/en-us/library/ms189128.aspx
( GrumpyOldDBA に感謝)
作業しているサーバーやデータにこれらの制限的なアクセス許可を設定する必要がない場合は、SQL Server で起動フラグを設定して、この関数をオーバーライドできます。Microsoftがこれで何をしようとしているのか理解しています.DBを切り離すと、誰かがファイルを持って立ち去ることを望んでいないと彼らは想定しています。しかし、優秀なハッカーにそれをさせないようにすることは、言うは易く行うは難しであり、DB を暗号化することがデータを保護する最善の方法だと思います。
とにかく、トレースとは何の関係もないので、奇妙な名前の「Trace Flag 1802」があります。この動作を維持したい場合は、SQL 構成マネージャーで SQL スタートアップに追加する必要があります。
https://support.microsoft.com/en-us/kb/922804
私自身も同じ問題を抱えていて、StackExchange で答えを見つけました: https://dba.stackexchange.com/a/77683/11001