堀川です、こんにちは


-----Original Message-----
From: 西山　和昭 [mailto:who@example.co.jp] 
Sent: Friday, January 30, 2004 1:04 AM
To: who@example.ne.jp
Subject: [ml-msde-beg:01032] MSDE ７から MSDE2000 へアップした際、 MSDE7 のユーザでログインできない


今回の原因とは関係がありませんが、データベースファイルの
コピーなどをするときは、明示的にデタッチした後に、取り出す
ようにして下さい。

データベースサービスを止めた後に（電源を落とす）、データベース
ファイルをコピーしても、これはデタッチ扱いにはなりません。

デタッチは、データファイルの中に、書き込み未完了が存在しない
ことを保証します。
このため、場合によっては、トランザクションログファイルが存在
しない状態でも、データベースを復元できるメリットがあります。
ただしこれには条件があって、トランザクションログファイルは
１個から構成されること。
#詳細は、２月２０日の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などを使って、ログイン情報も転送します。


------------------------------------
（株）日本技術ソフト開発
  　    　堀川　明  (Akira Horikawa)
    ０１月３０日（金曜日）　１４時２０分記
        mailto:who@example.ne.jp
        http://www.horikawa.ne.jp/msde/