早速のご教授ありがとう御座います。

> 
> 今回の原因とは関係がありませんが、データベースファイルの
> コピーなどをするときは、明示的にデタッチした後に、取り出す
> ようにして下さい。
> 
> データベースサービスを止めた後に（電源を落とす）、データベース
> ファイルをコピーしても、これはデタッチ扱いにはなりません。
> 
> デタッチは、データファイルの中に、書き込み未完了が存在しない
> ことを保証します。
> このため、場合によっては、トランザクションログファイルが存在
> しない状態でも、データベースを復元できるメリットがあります。
> ただしこれには条件があって、トランザクションログファイルは
> １個から構成されること。
> #詳細は、２月２０日のPASSJカンファレンスで触れる予定です。
> http://www.sqlpassj.org/conf2004/session.aspx
> 
> 
> データベースサービスを停止した後に取り出したファイルを使って
> 組み込むような場合は、トランザクションログファイルが必要です。
> データファイルに対する書き込み未完了部分は、トランザクション
> ログファイルから復元されます。
> 
> このような高信頼性機構が働くため、データファイルへの書き込みは
> オンメモリ上でキャッシュされ、データアクセスを高速化するのに
> 役立っているわけです。


ご指摘ありがとう御座います。


> さて、ご質問の内容ですが、
> 
> (1)MSDE7のデータファイルをMSDE2000に組み込んだ
> (2)データベースユーザに対応するログイン名が作成していなかったので、
> 新しくログインを登録した
> (3)ところがデータベースユーザとして、そのデータベースが使えない
> 
> という状況が起きているという意味でしょうか？


その通りです。


> 
> データベースユーザとログイン名の概念が部分的に混乱しているようなので
> 上記の場合についてアドバイスします。
> 
> まず、ログイン名の情報はmasterデータベースのsysxloginsシステムテーブル
> で管理されます（SQLServer2000）。
> 一方、データベースユーサは、個別データベースの中の、sysusers　システム
> テーブルで管理されます。
> 
> データベースだけの移動ですから、データベースユーザ情報は移動されるのに、
> masterデータベースのログイン情報は移動されませんでした。
> 
> このため、データベースユーザに対応するログイン名が、未対応になります。
> 
> そこで新しく、元と同じ名前のログイン名を作成したとします。
> 同じ名前だから大丈夫かと思いますが、内部的には名前ではなく、
> SID（セキュリティ識別子）で管理されます。
> 
> 元の名前と同じでも、ＳＩＤが異なると、別物扱いにされます。
> 
> データベースユーザを管理する sysusersテーブルでは、ログイン名に対応する
> SIDを覚えています。
> 
> そこで新しくログインを登録するときは、SIDを指定して登録します。
> 
> sp_addlogin [ @loginame = ] 'login'
>     [ , [ @passwd = ] 'password' ]
>     [ , [ @defdb = ] 'database' ]
>     [ , [ @deflanguage = ] 'language' ]
>     [ , [ @sid = ] sid ]
>     [ , [ @encryptopt = ] 'encryption_option' 
> 
> パラメータの５番目を指定します。
> 
> 
> 具体的には次のように、現在のデータベースユーザに対応するSID値を
> 探します。
> SQLServerログインに関しての場合です。
> 
> select  sysusers.sid               as 個別DB側SIDの値,
>         sysusers.name              as データベースユーザ名,
>         master.dbo.sysxlogins.sid  as システム上のSIDの値,
>         master.dbo.sysxlogins.name as ログイン名
>   from sysusers
>    left outer join master.dbo.sysxlogins
>        on sysusers.sid = master.dbo.sysxlogins.sid
>   where (
>            sysusers.issqluser=1
>      and 
>            sysusers.name<>'guest'
>    )
> 
> 上記を実行すると、データベース側で記憶しているSID値がわかります。
> また、対応が取れていないシステム側のSID値がNULLと表示されます。
> 
> システム側SID値がNULLになっているところの、データベース側SIDを
> 控えておきます。
> 
> 例えば、
>                        0x9DFDADFF65E38C4E975B5B361EF3C722
> のような値でしょう。
> 
> 
> 次に、対応が取れていないログインを削除します。
> 　　　　　　exec sp_droplogin  'ログイン名'
> 
> もう１度、新しくログインを登録し直します。その時、SID値を指定します。
>   exec  sp_addlogin
>                'ログイン名'  ,
> 　　           'パスワード' ,
>                 '既定のDBの名前' ,
>                null,
>               0x9DFDADFF65E38C4E975B5B361EF3C722
> 
> 以上で、対応関係が復活します。
> 
> 
> データベースを移動するときは、masterデータベースのログイン情報が
> どうなっているか考えて移動するようにしましょう。
> 
> 通常は、DTSなどを使って、ログイン情報も転送します。
> 

詳細な説明をありがとう御座います。
頑張ってみます。