このOffice 2000 Personalは、メーカー製Windows98やMEマシンにプレインストールされ出荷されていたものを外販パッケージ売りされたものです（マイクロソフト、『Office 2000 Personal』をパッケージ化して店頭で発売）。

この製品パッケージを中古ショップやオークションで探すよりも、むしろ、その当時に膨大に出荷されていたプリインストールパソコンに付属していたOffice 2000 PerosonalのCD-ROMを探す方が容易です。

中古ショップでその当時のデスクトップパソコンやノートパソコンを調べ、付属品が揃っていたら、そのパソコンを購入し、Outlook2000を入手しましょう。

Outlook2002とExchangeサーバーとの組み合わせであれば送信できますが、通常のインターネットメール（SMTP）では、この問題を解決することができないようです。

Outlook2000にして下さい。

WindowsXPPro版(SP2)+MSDE2000 Release-A+sqlmap70.dllコピー+Outlook2000の組み合わせで、試験しました。

質問番号00410,00440の電子メール送信機能が正しく働くかどうか調べました。

WindowsXPはログインしない状態で、データベースサービスとAgentサービスだけを、デーモン形式で動かしています。

その結果、サービスパックを適用しても、正しく通知されました。

Outlook2000 製品版インストール直後	Outlook2000のバージョン番号 9.0.02814
Office-2000 SR-1適用	9.0.0.3821
Office-2000 SP-2適用	9.0.0.4527 SP-2の適用後から、セキュリティアップデート版と表示されます
Office-2000 SP-3適用	9.0.0.6627
その他のセキュリティパッチ適用後	9.0.0.6627

上記の組み合わせすべてで、動作確認ができました。
警告発生時に、電子メールが送信されました。
但し、MSDE2000では、SQL Mail機能は使えないことになっています。

【注意(2006.5.16追記)】
WindowsXP Pro版のライセンス使用許諾書（eula.txt）では、WindowsXPに対してネットワーク外部から 接続を行なうソフトウェアに制限があり、データベースサービスはその制限に該当します。 ここでは試験目的ではありますが、ライセンス違反を犯していることをお詫び致します。

拡張ストアドプロシージャが、どのDLLファイルを使用するのか調べる命令があります。

xp_startmail 拡張ストアドプロシージャは、sqlmap70.dll ファイルによって提供されていることがわかります。

sqlmap70.dll ファイルは、SQLServer 2000 では、

に、インストールされています。

ところが、MSDE 2000 では、このファイルは、存在しません。
DLLファイルが存在しないので、そのDLLファイルを読み込むことは当然できません。

ですから、xp_startmail 拡張ストアドプロシージャは実行できないわけです。

ここで疑問が浮かびます。

sp_helpextendedprocストアドプロシージャは、データベースシステムに登録された拡張ストアドプロシージャのDLLファイルを報告する命令です。
この命令を実行すると、xp_startmail 拡張ストアドプロシージャは、MSDE2000のシステムに正式に登録されていると報告をします。
それなのに、DLLファイルが存在しないとは？

マイクロソフトのサポート情報311231番の Q15 を見ると、

と書かれています。

サポートされていないのではなく、単なるDLLファイルが提供されていないのでは？と考えたくなります。

もし「サポートされていない」が事実であれば、sp_helpextendedprocによる調査で、「存在しません」と判定されると思います。

試しに、SQL Server 2000用のsqlmap70.dllファイルを MSDE 2000 にコピーしてみました。

そして、私は、MSDE2000を使って、質問番号240番から440番までのSQL MailやSQLServer Agent Mailの機能について解説記事を書きました。

この解説記事をMSDE2000を使って書きましたが、今のところ、障害のような事態は起きておりません。DLLファイルがあれば、MSDE2000でも、SQL Mail機能が使えるように思えますが、何か障害が出るのでしょうか？

DLLファイルをMSDE2000ユーザに提供して下されば、SQL MailやSQLAgent Mail機能が使えるようになると私は思います。

私は、MSDE2000に適用しているサービスパック番号と同じ番号の、SQLServer 2000のサービスパックの中から、DLLファイルを取り出してきました。

SELECT * FROM master.dbo.sysmessages where error=18278 で検索できます

エラーメッセージ番号18278番の警告を作成し、オペレータとの関連付けを行ないます

SQLServer Agentが、警告を検出して電子メールを送信する仕組みは、SQLServerの中で実行されるSQL文の実行を監視するのではなく、SQLServerがSQL文の実行結果などをエラーログファイルに書き込みます。このエラーログファイルに書き込まれた内容をSQLServer Agentが監視します。

ですから、警告やオペレーターを正しく定義しても、その肝心の警告で発生された内容がエラーログファイルに書き込まれなければいけません。

RAISERROR命令では、With Logオプションを付けて実行すると、エラーログファイルにも、その内容が書かれます。

次に、通知の原因となる警告を作成します(sp_add_alert)。

最後に必要となる操作は、警告とオペレータの関係の登録です。警告が発生したら誰に電子メールを送信するかの登録です。

この作業は、sp_add_notificationストアドプロシージャで行ないます。

exec msdb.dbo.sp_add_notification '警告名','オペレータ名',通知手段番号（電子メールは1です）

その登録方法が、「警告の作成」と呼ばれます。

例えば、重大度レベル１番の番号を、警告として登録するときは、次のような命令を実行します。

exec msdb.dbo.sp_add_alert
       @name = '警告名称：重大度番号１番' , 
       @message_id =  0,
       @severity   =  1,  --この番号に、重大度レベルの数字を指定する
       @enabled    =  1

sp_add_alertやsp_delete_alertは、Books onlineに掲載されたストアドプロシージャです。

このプロシージャは、msdbデータベースに収録され、そのSQL文の処理の内容を見ることができます。

EXEC msdb.dbo.sp_set_sqlagent_properties @email_profile='プロファイルの名前'

メール送信を行なう前に、OUTLOOKがメールを受信する動作が行なわれます。

このため、正しいアカウントを登録しないと、タイムアウトなどが発生するまで、待機させられます。

	Outlook2000の受信用アカウントのパスワードを、わざと間違ったものを登録しました。メール送信が完了するまで、５分８秒も掛かりました。
	Outlook2000の受信用アカウントのパスワードを、正しいものを登録しました。メール送信が完了するまで、わずか３秒でした。 SQL Server 2000 で、メール受信処理をする予定が無くても、アカウントは正しいものを登録しましょう。

次のような命令を実行して、メールが送信されるか確認して下さい。

 exec master.dbo.xp_startmail

 exec master.dbo.xp_sendmail
     @recipients = 'ここに、送信先メールアドレスを書いて下さい' ,
        @message = 'データベースサービスからメールを送信します' ,
        @subject = 'こちらは SQL Mail です'

 exec master.dbo.xp_stopmail

その状態でクライアントコンピュータから接続して、上記のSQL文を実行して、電子メールが送信できるかどうか確認して下さい。

この２つの命令が、上記のように、何もエラーメッセージを表示しないときは、レジストリに登録されたプロファイルが正しいことがわかります。

exec master.dbo.xp_test_mapi_profile  'プロファイルの名前'

exec master.dbo.xp_test_mapi_profile 'MS Exchange の設定'

このストアドプロシージャを実行して、エラーが表示されなければ、プロファイルは正しいことがわかります。

SQL Server 2000 で使用する次のレジストリに登録を行ないます。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer

上記レジストリの中に、MailAccountNameキーを作成し、プロファイルの名前を登録します。

なお、次のストアドプロシージャを実行すれば、「MS Exchange の設定」が登録されますので、この方法をおすすめします。

exec master.dbo.xp_instance_regwrite 
           'HKEY_LOCAL_MACHINE' ,  
           'SOFTWARE\Microsoft\MSSQLServer\MSSQLServer', 
           'MailAccountName' ,  'REG_SZ' ,  'Outlook2000で作成されたプロファイルの名前'

なお、レジストリにキーを登録したら、次の命令でその確認ができます。

exec master.dbo.xp_instance_regread 
           'HKEY_LOCAL_MACHINE', 
           'SOFTWARE\Microsoft\MSSQLServer\MSSQLServer', 
           'MailAccountName'

このプロファイルとは、電子メールの送受信設定などが定義されたファイルと考えて下さい。

現在ログインしているユーザが使用するプロファイルの名前を調べる方法はいくつかありますが、一番簡単な方法は、レジストリを見るのがよいでしょう。

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles

このレジストリを見ます。

この例では、２つのプロファイルが登録されているのがわかります。１つ目の名前は、Outlook です。２つ目の名前は、SQL Mail です（注意：自分で明示的にSQL Mailという名前を作成したのであり、SQL Server 2000 がこのような名前を作成したわけではありません）。

またこのユーザのデフォルトプロファイルは、Outlookになっていることがわかります。

Outlook2000 を、企業ワークグループモードでインストールした場合、プロファイルの名前の初期値は、「MS Exchange の設定」となっていると思います。

Enterprise Managerを使って、サービス開始アカウントの変更を行ないます。

	SQLServer Agentプロパティを表示して、サービスの開始アカウントを、システムアカウントから特定のアカウントに変更を行ないます。 Administrator権限を所持するユーザAさんに変更を行ないます。このユーザAさんによって、Outlook2000のセットアップが行なわれます。
	デフォルトのローカルシステムアカウントから、Administrator権限を所持するユーザAさんに、サービスの開始アカウントを変更します。
	Administrator権限を所持するユーザAさんに、アカウントを変更します。 「コンピュータ名\ユーザ名」で、アカウントを入力します。

以上によって、SQLServer Agentの、サービス開始アカウントが変更されました。

ところが、ローカルシステムアカウントの特別なユーザの場合、このHKEY_CURRENT_USERのレジストリは存在しないことになっています。

データベースサーバーをログインしない状態で動かしているときに、メールを送信する場合は、Outlook2000で設定されたユーザ情報を、参照することができません。

そこで、データベースサーバーのサービス開始アカウントを明示的なユーザ名に変更をします。そしてこのユーザによって、Outlook2000のメール送信設定を行なって下さい。

具体的な操作としては、データベースサービスの開始アカウントを、ローカルシステムから、Administrators管理者グループに所属するユーザAさんに、変更を行ないます。そして、ユーザAさんがWindowsにログインして、ユーザAさんのOutlook2000のセットアップを行ないます。Outlook2000のインストールは、ユーザAさんで行ないます（ユーザAさんは、Administratorの名前でもよいです）

データベースサービスの開始アカウントの変更操作は、マイクロソフトサポート文書番号:283811でも解説しているように、Enterprise Managerを使わないと非常に難しい操作となります。そこでここでは、Enterprise Managerを使って操作を行ないます。

SQL Server 2000がインストールされた同じコンピュータ上にあるEnterprise ManagerをAdministrator権限のある人が立ち上げて、アカウントの変更操作を行ないます。

別のクライアントコンピュータにインストールされたEnterprise Managerを使う場合は、セキュリティ上のトラブルが発生することがあります。サービスのアカウント変更操作は、サービスがインストールされたコンピュータ上で操作を行ないましょう。

	SQL Server 2000 の、データベースサービスの開始アカウントが、システムになっています。これを変更します。
	インストール直後は、ローカルシステムアカウントになっている。このアカウントを変更します。
	Administratorsグループに所属するユーザ名に、変更します。 「コンピュータ名￥ユーザ名」の形式で、入力します。

以上の操作によって、データベースサービスの開始アカウントが、ローカルシステムから、特定のAdministrator権限を持つユーザに変更されました。
この方によって、Outlook2000のセットアップ処理を行ないます。

	Office-2000の中の、Outlook2000だけを取り出してインストールします。WordやExcelなどは、新しいバージョンを入れるとよいでしょう。
	Outlook2000の、インストールを始めます
	メールサービスオプションを、「企業／ワークグループ」として、インストールを行ないます。 間違って「インターネットのみ」でインストールしそうですが、SQL Server 2000 で利用する拡張MAPI接続は、「企業／ワークグループ」で提供されます。
	今回はExchangeサーバーは導入しないので、インターネット電子メールだけを組み込みます
	SQL Server 2000 から送信されるメールの、メールアドレスや名前を入力します
	SMTPサーバーのアドレスと、POP3サーバーのアドレスとそのアカウント情報を入力します。 SQL Server 2000 によって、受信したメールを読む操作を行なう予定が無い場合でも、受信用のアカウントとパスワードは、正しいアカウントを入れて下さい。 SQL Mail機能のメール送信命令のxp_sendmailストアドプロシージャの実行では、Outlook側で、POP3サーバーへのログインの試みが行なわれていました。メールを受信しようとしており、パスワードが違っていると、リトライなどで長時間待たされます。
	メールの送受信は、必ずLAN接続です。
	メール送受信の、詳細設定を行ないます。既定のままです。
	メールボックスに相当する、個人用フォルダファイルの保存場所を定義します。既定の場所から、わかりやすい場所に移すとよいかも知れません。
	以上で、Outlook2000の、インストール時のセットアップは完了しました。
	Outlook2000を、通常使う電子メールソフトにします。 インターネットエクスプローラー（IE）のインターネットオプションのプログラムの設定でも、その変更を行なうことができます
	Outlook2000の送信メール形式は、HTML書式が既定になっています。それを、テキスト形式に直します。
	SQL Server 2000 では、受信メールを読み取るような操作は、行ないません。そこで、新着メールの確認オプションを、外します。 Outlook2000では、セキュリティ上の問題が数多く発生しております。このため、電子メールを受信すると、データベースサーバーに悪影響がでる可能性があります。 安全を期して、SQL Server 2000 では、メール送信だけを行なうようにします。

メールを作成し、送信してみて下さい。このとき、「送信」ボタンを押したら、すぐにメールが送信されることを確認してください。

送信フォルダにメールが残っているような状態では、自動送信を行なうことはできません。

実際に送信されたメールは、「送信フォルダ」から「送信済みフォルダ」に移されます。

しかし通常は、データベースサーバーは、誰もログインしていない状態にするのが常識です。

このような一般的な運用環境では、実は、Outlookのバージョンに注意が必要になります。

ログインしていないので、Outlookがダイアログボックス等を表示したら、そこでメール処理が 止まってしまいます。ですから、Outlookがユーザ操作を要求しないことが必要条件になります。

しかしマイクロソフト社のオフィス開発チームは、様々なセキュリティ問題に対処するため、Outlookのセキュリティ機能を強化しました。これが反って災いになります。

そこでOutlookのセキュリティが強化されたバージョンを使うと、外部から拡張MAPI接続が行なわれると、様々な場面で、ユーザに許可を求めるダイアログボックスが表示されたりします。

このようなOutlookのセキュリティ機能が組み込まれたバージョンでは、SQL Mail や SQLAgent Mail は正しく動きません。

SQL Mail や SQLAgent Mail と一番相性の良いOutlookは、2000 です(Office-2000製品)。

Outlook2000では、セキュリティ機能が組み込まれても、SQL Server 2000と一緒に使うことができます。

SQL Mail や SQLAgent Mail 機能は、データベース開発では便利な機能です。この機能を生かすためにはOutlook2000という古いソフトが必要となります。Outlook2000を必ず入手して下さい。

なお、Exchangeサーバーを導入すると、このような相性問題が解決できます。

Outlookのバージョンで、2000、2002(XPのこと）、2003の製品です。
使用上の注意がありますが、Outlook98も対応します。

なお、Outlook Express は、拡張MAPI接続には対応していません。

MSDE や SQL Server をインストールしたコンピュータ上に、Outlookも一緒にインストールして下さい。

データベースサーバーとOutlookを、別々のコンピュータに入れることはできません。

詳しくは、
マイクロソフトサポート文書番号：263556
マイクロソフトサポート文書番号：315886
を参照下さい。

例えば、テープ装置にデータベースをバックアップするジョブで、ジョブが失敗したときに、電子メールを送信するように設定します。
通常のバックアップは正常終了するのですが、テープが一杯になってテープ交換が必要になったら、そのバックアップジョブは失敗し、システム管理者に、テープ交換が必要だという電子メールが入ります。

遠隔地にあるデータベースサーバーで、時々しか現場に行けないような場合は、現場作業が必要になるタイミングで、管理者を呼び出すトリガとして、SQLAgent Mail を活用すると便利です。

ただ実際は、その電子メールが入ること自体は、管理者の手抜きだと言われますが。。。。
管理者が現場に駆けつけたら、サーバーがダウンしているかもしれません。
本来は、警告やエラーメールが通知される前に対処しなければいけません。

また、データベースシステムで発生した何かの警告メッセージやエラーメッセージなどをシステム管理者に電子メールで通知することもできます。

このような、ジョブの実行結果通知やデータベースシステムの監視結果通知は、Windowsのイベントログなどに記録することができますが、それを管理者あてに、電子メールで通知することができるようになっています。この電子メールによる通知機能が、SQLAgent Mail と呼ばれます。

SQL Mail のような、SQLプログラミングの中で使うものではありません。
SQLServer Agent に対する、電子メールを送信するための送信条件を定義する作業となります。

SQLAgent Mail でも、実際の電子メール送信機能は、拡張MAPI接続に対応した電子メールクライアントソフトがその送信実務を担当します。

この拡張ストアドプロシージャを使った場合は、暗黙のうちに、SQL Mail 機能を呼び出していることになります。

SQL Mail では、次の拡張ストアドプロシージャが提供されます。

上記の、ストアドプロシージャを使ったプログラミングが、SQL Mail と呼ばれます。

「電子メールの読み込み」とは、拡張MAPI接続対応のメールクライアントソフトが読み込んだ電子メールの受信トレイからメールを読み出す機能です。

「電子メールの削除」とは、拡張MAPI接続対応のメールクライアントソフトが読み込んだ電子メールを削除する機能です。

「電子メールの送信」とは、拡張MAPI接続対応のメールクライアントソフトに対して、電子メールの送信を依頼する機能です。

どちらの方法でも、「拡張MAPI接続」に対応したメールクライアントソフトウェアをSQLServer 2000 データベースサーバーをインストールしたコンピュータに、一緒に入れる必要があります。

SQLServer 2000 自身が、SMTPなどの電子メールプロトコルを話すわけではありません。

SQLServer 2000 が、拡張MAPIに対応したメールクライアントソフトウェアに対して、送信したいメールを依頼します。
実際の送信は、拡張MAPIに対応したメールクライアントソフトウェアが担当します

つまり、SQLServer 2000 の電子メール機能とは、拡張MAPI接続に対応したメールクライアントソフトウェアと一緒に、拡張MAPI接続機能を使って協同作業ができるという意味です。

SQLServer 2000 の単独だけでは、電子メールの送信はできません。

ERRORLOG ファイルは、WindowsのAdministrator権限を持っている人が閲覧することができます。一般のユーザはその中身を確認することはセキュリティ上許されません。

製品区分	データベースサービス（Sqlservr.exe）のバージョン
リリース出荷製品（RTM）	2000.8.00.194
SQL Server 2000 SP1	2000.8.00.384
SQL Server 2000 SP2	2000.8.00.534
SQL Server 2000 SP3	2000.8.00.760
SQL Server 2000 SP3a	2000.8.00.760
SQL Server 2000 SP4	2000.8.00.2039

 
参照：マイクロソフトサポート文書番号：321185

番号,日付,ファイルサイズ

の表が得られますので、その中のファイルサイズ列から、ログファイルの大きさがわかります。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\NumErrorLogs
値は REG_DWORD 型

NumErrorLogs の値を、10進数で、10と設定すれば、

までの、合計10個の過去のエラーログファイルが保存されます。

また、現在使用している ERRORLOG ファイルはデータベースサービスによって開かれており、メモ帳等の他のソフトによって、エラーログの内容を変更することはできません。

特別な目的があって、データベースサービスを運用している最中に、このエラーログファイルの更新を行ないたいことがあります。

そのような場面では、ストアドプロシージャ sp_cycle_errorlog を実行して下さい。

sp_cycle_errorlog ストアドプロシージャのかわりに、このDBCCコマンドを実行しても同様の結果が得られます。

データベースで管理できれば、メッセージ内容をSQL文で検索できたりして、とても便利です。

しかしデータベースサーバーが起動できないほどの致命傷が発生したときは、データベース内部のデータを調べることができず、その原因を追究することができません。このような理由から、データベースサービスで出力されるメッセージは、データベースとは異なるテキストファイルで記録されます。

しかし工夫すれば、エラーログファイルに記録されるメッセージ内容を、別途データベース内部のテーブルに保存することは可能になります。

次のような手順で作業して下さい。

なおここでは、CPANから取得したPerlで記述されたtail コマンドを使います。

このプログラムは、tail -f コマンドをパイプによって実行し、その標準出力に出力される内容を読み込みます。

読み込まれた文字列をパーツに分解して、INSERT命令を組み立てます

Perl言語の中から、ADO接続オブジェクトを作成し、ConnectionオブジェクトのExecuteメソッドを利用して、INSERT命令のSQL文を実行し、ERRORLOGファイルに記録されたメッセージをデータベースのテーブルに保存します。

この tail コマンドのソースプログラムを取得します。

このWebブラウザに表示された内容をすべて選択し、コピーして、テキストファイルに貼り付けて下さい。 tail.pl という名前で保存します。

Windowsのコマンドプロンプトから次のように実行して下さい。エラーログファイルを常時監視することができます。

perl tail.pl -f "C:¥Program Files¥Microsoft SQL Server¥MSSQL¥LOG¥ERRORLOG"

tail.plを使ったエラーログファイルの監視

「最新の情報に更新」を押さないと、いつまでも過去の状態を見ていることになります。
このため、データベースサーバーの運営状態を正確に把握する方法としては、Enterprise Manager は、適任ではありません。

リアルタイムに、エラーログファイルの内容を表示するソフトウェアが必要です。

このような分野では、テキストファイル処理に多くのコマンドを提供しているUNIX系のコマンドを探すとよいでしょう。

tail コマンドが代表格です。

で、テキストファイルに書き込まれるメッセージの内容を常時表示することができます。

tailコマンドは、Windowsのコマンドプロンプトで提供される標準コマンドの中には存在しません。このため、Windowsで動作するtailコマンドを作っている人が多数おられますので、そのようなサイトからダウンロードすることができます。

cygwinの中のtailコマンドを使ってエラーログファイルを表示しています。

エラーログファイルはテキストファイルなので、手軽な方法としては、『メモ帳』を使って、その中身を確認することができます。

データベースサービスが停止しているときは、ERRORLOG ファイルの内容をメモ帳から変更することができますので、誤って気がつかずにキーボードからキーを押して文字を入力することがないようにご注意下さい。

データベースサービスを提供している間は、データベースサービスが ERRORLOG ファイルを開いているので、メモ帳などからその内容を更新することはできません。

このため MSDE2000 でデータベースサーバーを運営していても、エラーログファイルの存在をまったく知らない方もおられます。

MSDE2000 だからと言って、データベースサーバーの監視業務をしなくてもよいとは、考えないで下さい。

SQLServer とまったく同様のデータベースエンジン性能を有していますので、快適なデータベースサービスを提供するためには、MSDE2000 でも、エラーログファイルの内容を正しく監視することが大事です。

次のディレクトリの中に、エラーログファイルが作成されます。

このディレクトリの中に、

              ERRORLOG
              ERRORLOG.1
              ERRORLOG.2
              ERRORLOG.3
              ERRORLOG.4
              ERRORLOG.5
              ERRORLOG.6

データベースサービスを起動すると、最後のエラーログファイル（ERRORLOG.6）は破棄されて、ERRORLOG.5ファイルがERRORLOG.6と名前が変更されます。ERRORLOG.4ファイルがERRORLOG.5と名前が変更されます。以下同様に、 ERRORLOGファイルが、ERRORLOG.1となります。

そして、新しく起動されたデータベースサービスが使うエラーログファイルが、ERRORLOGです。

MSDE や SQLServer （データベースサーバー） のエラーログファイルは、データベースサーバーが動作している間に発生した様々な情報メッセージや警告メッセージ、エラーメッセージなどが記録されるテキストファイルのことです。

エラーログファイルに記録された内容を監視することで、データベースサーバーの運営状態を把握することができます。

エラーログファイルに記録される一部のメッセージは、Windows側のイベントメッセージとしても、同じように記録されます。

このため、Windowsのイベントビューワーを使って、MSDE や SQLServer の監視を行なうこともありますが、正式には、データベースサーバーが記録しているエラーログファイルを監視するのがよいと思います。

dbo ユーザまたは db_owner データベースロールに所属している方が、この命令を実行してください。

誰でもこの命令を実行することができます。

この命令を実行すると、レコードセット（表）が返されます。その中の、MemberName列に、ユーザ名が表示されます。

次のようなSQL文を実行するとよいでしょう。

dbo ユーザの方が、この命令を実行します（または db_owner データベースロールに所属している人も実行ができます）

あなたが、

命令を実行してデータベースを作成しました。

あなたは、明日から３ヶ月間の長期出張に出なければいけません。

さて、長期出張している間、Customersデータベースの管理者が不在になります。非常に困ったことが起きました。

あなたが不在の間、新しいデータベースのユーザ登録は、誰が行なうのでしょうか？

テーブルに対するセキュリティの設定は、誰が行なうのでしょうか？

データベースのバックアップは、誰が行なうのでしょうか？

このように、dbo ユーザは、データベース管理者として、様々な仕事を行ないます。その dbo ユーザが不在になると、そのデータベースの運営に支障を来たすことがあります。

そこで、SQLServer では、dbo ユーザの仕事を、他のユーザに任せることができます（権限委譲）。

db_owner,db_accessadmin,db_securityadmin,db_ddladmin,db_backupoperator の各データベースロールが、仕事の分類に対応します。

この中で、db_owner は、「データベース内のすべての権限」を持つことができます。言うなれば、dbo ユーザの名代（分身？）として、働くことができます。

つまり、db_owner データベースロールに所属することは、dbo ユーザとまったく同等になります。

但し、注意点が１つだけあります。

それは、テーブルなどデータベースオブジェクトを新規に作成した場合の所有者名です。

dbo ユーザがオブジェクトを作成したときは、その所有者名は、dbo になります。

db_owner データベースロールに所属しているユーザがオブジェクトを作成したときは、その所有者名は dbo ではなく、本人のユーザ名となります。

dbo ユーザが留守の間に調子に乗って、テーブルなど新規に作成すると、後から所有者名を dbo に戻さなければいけなくなるような作業が出てきます。
ご注意下さい。

データベースを新しく作成する命令は、CREATE DATABASE 文です。このSQL文を実行した人が、dbo ユーザに該当します。

dbo ユーザは、そのデータベースに関するすべての権限が許可されています。SQL文を実行する前に、事前に命令の内容を確認することが大事です。
レコードを削除する DELETE 命令もすぐに実行できますので、重要なレコードを削除するときは注意が必要です。

データベースサーバーのサーバー管理者権限（sysadminと呼ばれる）を持っている人は、自動的に、個々のデータベースの dbo ユーザに割り当てられます。この結果、そのデータベースサーバーで作成されたあらゆるデータベースの所有者になります。

表示権限（SELECT権限）と挿入権限（INSERT権限）を同時に与える場合は、次のSQL文を実行します。

このSQL文は、許可を与えるテーブルの所有者の方が実行します

データベースに所属するすべてのユーザに対して許可を与えるときは、データベースユーザ名の部分をPUBLICロールとします。

この命令によってデータベースに所属するすべてのデータベースユーザが、テーブルに対して、SELECT命令とINSERT命令を実行することが許可されます。

SQLServer では、他人が作成したテーブルに対して、その作成者の許可を得ずに、そのテーブルのレコードを勝手に削除することはできません。

テーブルに対して、DELETE実行権限が与えられることによって、レコードを削除することができるようになります。

DELETE実行権限セキュリティが、許可されているかどうか、そのテーブルを作成した所有者の方に、確認を取って下さい。

データベースユーザ User_A さんが作成したテーブルTBL_Aに対して、DELETE実行権限セキュリティをデータベースユーザ User_B さんに与える命令は、次のように実行します。

このSQL文は、テーブルの所有者であるデータベースユーザ User_A さんが実行します。

GRANT命令（セキュリティを許可する命令）によって、データベースユーザ User_Bさんは、データベースユーザ User_Aさんが所有するテーブルTBL_Aに対して、DELETE命令を実行することができるようになります。

データベースに所属するすべてのユーザに対して、DELETE実行権限を許可するためには、データベースユーザ名の部分をPUBLICロールとします。

この命令によってデータベースに所属するすべてのデータベースユーザが、User-Aさんが所有するテーブルTBL_Aに対して、DELETE命令を実行することが許可されます。

データベースのテーブルを新しく作成したら、レコードの削除を誰に許可するのか、そのセキュリティについて考えなければいけません。

SQLServer では、他人が作成したテーブルに対して、その作成者の許可を得ずに、そのテーブルのレコードを勝手に更新することはできません。

テーブルに対して、UPDATE実行権限が与えられることによって、レコードを更新することができるようになります。

UPDATE実行権限セキュリティが、許可されているかどうか、そのテーブルを作成した所有者の方に、確認を取って下さい。

データベースユーザ User_A さんが作成したテーブルTBL_Aに対して、UPDATE実行権限セキュリティをデータベースユーザ User_B さんに与える命令は、次のように実行します。

このSQL文は、テーブルの所有者であるデータベースユーザ User_A さんが実行します。

GRANT命令（セキュリティを許可する命令）によって、データベースユーザ User_Bさんは、データベースユーザ User_Aさんが所有するテーブルTBL_Aに対して、UPDATE命令を実行することができるようになります。

データベースに所属するすべてのユーザに対して、UPDATE実行権限を許可するためには、データベースユーザ名の部分をPUBLICロールとします。

この命令によってデータベースに所属するすべてのデータベースユーザが、User-Aさんが所有するテーブルTBL_Aに対して、UPDATE命令を実行することが許可されます。

データベースのテーブルを新しく作成したら、レコードの更新を誰に許可するのか、そのセキュリティについて考えなければいけません。

SQLServer では、他人が作成したテーブルに対して、その作成者の許可を得ずに、そのテーブルに新しいレコードを勝手に挿入することはできません。

テーブルに対して、INSERT実行権限が与えられることによって、新しいレコードを挿入することができるようになります。

INSERT実行権限セキュリティが、許可されているかどうか、そのテーブルを作成した所有者の方に、確認を取って下さい。

データベースユーザ User_A さんが作成したテーブルTBL_Aに対して、INSERT実行権限セキュリティをデータベースユーザ User_B さんに与える命令は、次のように実行します。

このSQL文は、テーブルの所有者であるデータベースユーザ User_A さんが実行します。

GRANT命令（セキュリティを許可する命令）によって、データベースユーザ User_Bさんは、データベースユーザ User_Aさんが所有するテーブルTBL_Aに対して、INSERT命令を実行することができるようになります。

データベースに所属するすべてのユーザに対して、INSERT実行権限を許可するためには、データベースユーザ名の部分をPUBLICロールとします。

この命令によってデータベースに所属するすべてのデータベースユーザが、User-Aさんが所有するテーブルTBL_Aに対して、INSERT命令を実行することが許可されます。

データベースのテーブルを新しく作成したら、レコードの新規挿入を誰に許可するのか、そのセキュリティについて考えなければいけません。

SQLServer では、他人が作成したテーブルを、その作成者の許可を得ずに、そのテーブルのレコードの内容を勝手に表示することはできません。

テーブルに対して、SELECT実行権限が与えられて、初めてそのテーブルのレコードの内容を取得することができます。

SELECT実行権限セキュリティが、許可されているかどうか、そのテーブルを作成した所有者の方に、確認を取って下さい。

データベースユーザ User_A さんが作成したテーブルTBL_Aに対して、SELECT実行権限セキュリティをデータベースユーザ User_B さんに与える命令は、次のように実行します。

このSQL文は、テーブルの所有者であるデータベースユーザ User_A さんが実行します。

GRANT命令（セキュリティを許可する命令）によって、データベースユーザ User_Bさんは、データベースユーザ User_Aさんが所有するテーブルTBL_Aに対して、SELECT命令を実行することができるようになります。

データベースに所属するすべてのユーザに対して、SELECT実行権限を許可するためには、データベースユーザ名の部分をPUBLICロールとします。

この命令によってデータベースに所属するすべてのデータベースユーザが、User-Aさんが所有するテーブルTBL_Aに対して、SELECT命令を実行することが許可されます。

データベースのテーブルを新しく作成したら、テーブルのレコードの表示を誰に許可するのか、そのセキュリティについて考えなければいけません。