このトピックでは、Microsoft SQL Server 2000 への配備に関するよくある質問への回答が提供されています。このトピックは、付属の SQL Server データプロバイダと SQL インストールスクリプトを使用して、WebSchedule アプリケーションを配備しなければならない Web 開発者を対象としています。データ主導のスケジューリング アプリケーションでセキュリティと信頼性を計画するための実用的なアドバイスも提供します。
インストールの高度なカスタマイズはこのトピックの範囲外であり、データベース管理者（DBA）のサービスを必要とする場合があることを認識してください。バックグラウンド情報として、ここで提供されている回答を使用する場合、DBA に問い合わせてご使用のスケジューリングアプリケーションの要件に対応する必要があります。
Microsoft SQL Server に WebSchedule アプリケーションを配備する前に、ご使用のサーバー ホスト マシンが最小限のシステム要件を満たしていることを確認してください。 WebScheduleSqlClientProvider コントロールを使用するために Microsoft SQL Server 2000（またはそれ以降）、または Microsoft Database Engine（MSDE）の最新のサービスパックをインストールする必要があります。
WebSchedule データ モデルによって必要とされる必須テーブル、関係、ストアド プロシージャ、インデックス、デフォルト データを作成するために、WebSchedule は SQL インストール スクリプトをインストールします。このスクリプトを見つけることができるパスは、オペレーティングシステムによって、以下のデフォルト インストール フォルダとなります。
XP — C:\Documents and Settings\All Users\Documents\Infragistics\2023.1\ASP.NET\WebSchedule\Data
Vista — C:\Users\Public\Documents\Infragistics\2023.1\ASP.NET\WebSchedule\Data
このスクリプト ファイル名は WebSchedule で開始し、データ モデル スキーマのバーションを識別する番号が続き、ファイル拡張子 ".sql" が付きます。
デフォルトで、インストール スクリプトはファイル名をとってデータベース名を付けます（ つまり 、データ モデル スキーマ バージョンを識別する番号が WebSchedule の後に付きます）。任意の Unicode テキスト エディタ（Windows のメモ帳など）にインストールスクリプトをロードして、固有の名前でデフォルト名のインスタンスを置き換えることによって作成されるデータベースのデフォルト名を変更できます。
データベースを作成するために SQL インストールスクリプトを実行すると、SQL Server のデフォルト インスタンスのデフォルトの場所にデータ ファイル（*.MDF）とトランザクション ログ ファイル（* .LDF）が作成されます。
SQL Server Enterprise Manager 内でサーバーをマウスの右ボタンでクリックして、SQL Server のデフォルトの場所を設定します。コンテキスト メニューから [プロパティ] を選択すると、[SQL Server プロパティ] ダイアログが表示されます。[データベース設定] タブには、[新しいデータベースのデフォルトの場所] というラベルのパネルがあり、このパネルで初期データ ディレクトリとトランザクション ディレクトリを指定できます。
データ定義言語（DDL）に詳しいデータベース管理者は、SQL インストール スクリプトを変更して、ファイル グループ、成長の要因、RAID ディスクアレイのデータおよびトランザクション ログ ファイルの固有の配置を含み、より高度な配置を指定できます。変更するステートメントは SQL インストール スクリプト内の CREATE DATABASE 行です。CREATE DATABASE ステートメントをカスタマイズする時に使用できる広範なオプションは、このトピックの範囲ではありませんが、SQL Server Books Online でより詳細な情報を見つけることができます。
コマンドシェルからデータベースを作成するためにSQLインストール スクリプトを実行します。または SQL Server Enterprise Manager に添付されている SQL Query Analyzer（グラフィカル インタフェース）によって実行できます。MSDE にはグラフィカルインタフェースが含まれていないことに注意してください。MSDE に配備する場合にはコマンド シェルを使用する必要があります。
SQL インストール スクリプトが配置されている作業ディレクトリのコマンドシェル（[スタート] メニュー | [ファイル名を指定して実行] | "cmd"）で、一般的な sa アカウントで SQL 認証モードを使用する時に、以下を入力します。
osql -i WebSchedule1.sql -U sa -P passwordまたは Windows 認証モードでは:
osql -i WebSchedule1.sql -Eこれらはマシン上のデフォルトの SQL Server インスタンスのための指示です。複数の SQL Server インスタンスがある場合、非デフォルト インスタンスを指定するために -S [ serverName \ instanceName ] 引数を追加できます。たとえば以下のようになります。
osql -i WebSchedule1.sql -E -S "MACHINE\VSdotNET"SQL Query Analyzer 環境内で、最初に以下のようなログオン ダイアログによって WebSchedule データ モデルをインストールしたい SQL Server インスタンスに接続します。
正しい認証モデル（SQL または Windows）とサーバー名を指定します。ローカル マシンでのデフォルト サーバーを指すために、"."を残すことができます。非デフォルト SQL Server インスタンスを選択する場合、サーバー名とインスタンス名の両方をスラッシュ（\）によって分離して指定する必要があります。[OK] をクリックしてログオンします。
クエリ ウィンドウが表示されます。[ファイル] メニューで、[開く] を選択し、次に Ultimate UI for ASP.NET とともにインストールされた SQL インストール スクリプトを選択します。このインストール スクリプトがロードして、F5 を押して SQL インストールスクリプトでバッチコマンドを実行する前に、クエリ ウィンドウで変更できます。
SQL インストールスクリプトの実行には、15 秒から 30 秒かかります。標準の出力（コマンド シェルを使用すると）または結果ウィンドウ（SQL Query Analyzer を使用すると）にエラーが表示されます。作成された新しい WebSchedule データベースを確認するために、SQL Query Analyzer でドッキングされた [オブジェクト] パネルを更新しなければならない場合があります。
Microsoft SQL Server が SQL 認証モードを使用するのか、Windows 認証モードを使用するのかを確認するには、SQL Server Enterprise Manager でサーバーを選択します。右クリックして、コンテキスト メニューから [プロパティ] を選択します。[セキュリティ] タブを選択して、アクティブな認証モードをチェックします。
WebSchedule を使用する時に SQL 認証モードと Windows 認証モードについて知っておく必要がある違いに関する詳細は、
ink:webschedule-sql-authentication-in-microsoft-sql-server.html[「Microsoft SQL Server での SQL 認証」]または 「Microsoft SQL Server での Windows 認証」を参照してください。
実稼働環境で WebScheduleSqlClientProvider を使用して WebSchedule アプリケーションを実行するときには、フォームにドロップする ADO.NET SqlConnection コンポーネントの ConnectionString プロパティに、配備した Microsoft SQL Server への接続パラメータを定義する必要があります。ConnectionString がビューステートで表示されてはならない機密データを含んでいることに注意してください。
各ページ要求ごとに（または接続プーリング状況で SqlConnection を初期化する時に）WebScheduleSqlClientProvider コントロールに関連付けられているこの ADO.NET SqlConnection コンポーネントに ConnectionString を設定する必要があります。アプリケーションの「web.config」ファイルまたは暗号化した形式で保存するなど、この情報の安全性を保証するためのベストプラクティスを使用することによって、ConnectionString でログオン情報を常に保護します。
WebScheduleSqlClientProvider は、SqlConnection コンポーネント名（ つまり SqlConnection1）のみを保持し、これを使用して機密情報を必要としない各要求で Microsoft SQL Server との接続を再構築します。動的に作成された SqlConnection コンポーネントをランタイムにデータ プロバイダの Connection プロパティに割り当てることも可能です。したがって、使用できない場合には、設計時に SqlConnection コンポーネント名を知る必要はありません。
データ プロバイダがデフォルト接続を使用して動作しますが（ブランク パスワードの標準的な SQL 認証ログオン「sa」を使用してローカルマシンでのスキーマバージョン番号が続く「WebSchedule」という名前のデータベースに基づいて）、実稼働環境ではこの接続に決して依存しません。ローカルマシンでアプリケーションを開発する時便宜上含まれるだけです。前述のように、WebSchedule データプロバイダをデータベースに正しく接続せずに配備して、「sa」とブランクパスワードを使用して接続するデータ プロバイダのためのデータベースがない場合、接続がないことに対してエラーが発生した時にデータ プロバイダがこの状況に対する警告を通知します。
スケジューリング アプリケーションが配備される前に、DBA に相談してアプリケーションのバックアップおよびリストア プロセスの計画は慎重に行う必要があります。プロセスに任意の期間データベース サーバーをオフラインにすることが含まれている場合、ダウンタイムのユーザー インタフェースを Web アプリケーションに組み込むことを検討してください。
WebSchedule は任意のバルク操作を実行しません。したがって、Web アプリケーションが固有のバルク操作（たとえばスケジューリング情報をオフサイトから夜間にインポートする）を実行しない場合、バルクログ復元モデルを使用できます。
デフォルトで WebSchedule はトランザクションログを作成します。SQL インストールスクリプトで CREATE DATABASE ステートメントを変更する、またはトランザクション ロギングの特性を変更するために配備後に ALTER DATABASE ステートメントを実行できます。トランザクションロギングをオフにすると、単純な復元のみが可能となり、最後のフルデータベース バックアップ以降行った任意のデータ変更を再実行する必要があり、そうでない場合は失われます。
WebSchedule の将来のリリース（およびホットフィックス リリース）は、新しい機能をサポートする（または問題を修正する）ために WebSchedule データ モデルへの変更を行う可能性があります。データ モデルはこの種類の拡張性を念頭に置いて開発されています。データ モデルの新しいスキーマバージョンがリリースされると、スキーマ バージョン番号が増え、スキーマ バージョンが増分して変更されるたびに初期のスキーマに合致するデータベースを更新したスキーマに変換する SQL スクリプトが提供されます（たとえば 1 から 2、2 から 3 というように ）。後方互換性を最大限に保証するために、新しい列と関係にデフォルト データが入ります。
一部の開発者は、列を追加する、またはストアド プロシージャを変更して固有の拡張を追加することによって、データ モデルにカスタマイズを行っている場合があります。列名の競合を回避するために、アプリケーションによって追加されたコラムに名前を指定する時に開発者は小文字を使用します（リリースされた WebSchedule データ モデルのすべての列は継続して大文字の命名規則を使用する、または先行する下線を予約した列に付けます）。リリースされた WebSchedule データ モデルへの更新は、このようなカスタマイズとの互換性を保証できません。ストアド プロシージャの定義が変更される場合、ストアドプロシージャへのカスタマイズを再度実行する必要があります。またはカスタム データ モデルに合うように、増分するアップグレード スクリプトを変更する必要があります。
アップグレード SQL スクリプトを適用する前に、データベースのフルバックアップを実行することを推奨します。そうすることで、アップグレード中にエラーが発生した場合にオリジナルのデータベースに復元できます。