必要なソフトウェア: SQL Server 6.0 Service Pack 3 日本語版は次のサイトからダウンロードできます。
http://www.microsoft.com/japan/bkoffice/ntsql/in_pack.htm
日付の処理:
1) サーバー:
SQL Server には、datetime と smalldatetime の 2 つの日付/時刻データ型があります。datetime データ型は 2 つの 4 バイトの整数 (8 バイト) で保存されます。最初の 4 バイトは、基準日付である 1900 年 1 月 1 日までの日数またはそれ以降の日数、残りの 4 バイトは午前 0 時 0 分 0 秒以降のミリ秒数を表します。datetime の対応期間は 1753 年 1 月 1 日から 9999 年 12 月 31 日です。精度は、300 分の 1 秒 (3.33 ミリ秒) です。
smalldatetime データ型は datetime よりも精度が低くなります。このデータ型は 4 バイトで保存されます。最初の 2 バイトには 1900 年 1 月 1 日以降の日数が保存され、残りの 2 バイトには午前 0 時 0 分以降の分数が保存されます。 smalldate の対応期間は 1900 年 1 月 1 日~ 2079 年 6 月 6 日までです。精度は、分単位です。
どちらのデータ型でも西暦の下 2 桁での指定を許可しています。ただし、下2桁で指定された場合でも 4 桁の西暦として保存されます。下 2 桁として、50 以下が指定された場合は、西暦 20XX と解釈され、50 より大きい値が指定された場合は 19XX と解釈されます。たとえば、"03" が指定された場合、西暦 2003 として保存されます。"82" が指定された場合、西暦 1982 として保存されます。
2) SQL 管理ツール:
SQL Server 管理ツールには、SQL Enterprise Manager、ISQL/w、セキュリティ マネージャ、クライアント設定ユーティリティ、 サービス マネージャ、および SQL Server Executive があります。これらの一部では、日付情報の表示と入力を行うことができます。
日付の表示:
SQL Server エンジンの表示形式または Windows NT コントロール パネルの表示形式を使用します。
日付の入力:
日付の入力には、編集フィールドまたは日付コントロールが使用されます。サーバーに日付情報をトランスポートする手段としては、ストアド プロシージャ、SQLOLE、 DB-Library、 SQL Server ODBC ドライバ、および Net-Library があります。 入力された日付の有効性は、datetime データ型に対して SQL エンジン レベルで検証されます。SQL Server Executive と SQL Server のタスクと警告スケジュール エンジンは例外です。スケジュール タスクの日付情報は整数データ型で保存され、入力した日付の有効性はユーザー インターフェイスの日付コントロールで検証されます。また、データベースに保存される前に、ストアド プロシージャ内の SQL Server の ISDATE() 関数で検証されます。
下 2 桁の西暦の処理:
SQL Server エンジンでは、日付を datetime データ型の西暦 2 桁として入力できます。西暦が下 2 桁で入力された場合も、上記の説明のように 4 桁の西暦として保存されます。。下 2 桁として、50 以下が指定された場合は、西暦 20XX と解釈され、50 より大きい値が指定された場合は 19XX と解釈されます。たとえば、"25" が指定された場合、西暦 2025 として保存されます。"50" が指定された場合、西暦 1950 として保存されます。
SQL Server 6.0 Service Pack 3 の問題点は ? SQL Server 6.0 Service Pack 3 テスト結果により、次の問題が発見されています。
- DUMP DATABASE の EXPIREDATE 句は 2000 年以降の日付が正しく処理されません。EXPIREDATE はバックアップ メディアを再利用できるかどうかを示す場合に使用されます。この問題が発生しても、 SQL Server の通常の運用には影響しません。影響は間違ってバックアップ メディアの上書きをしてしまうことと、EXPIREDATE で提供されるほかの安全性のチェックが行われないことだけです。
- DUMP DATABASE の RETAINDAYS はシステム日付が 99 年 12 月 31 日を経過すると問題があります。存在するダンプを上書きできなくなります。回避策としては、ダンプの前に存在するダンプを事前に削除しておきます。
- SQL Executive は 2000 年をうるう年として認識しません。
- タスク マネージャのユーザー インターフェイスのスピン ボックスは 2000 年をうるう年として認識しません。回避策は、タスクのスケジュールをユーザー インターフェイスでなく、直接ストアド プロシージャを実行するとこにより行います。
- SP_ADDTASK、SP_PURGEHISTORY と SP_UPDATEALERT ストアド プロシージャは不正な日付を入力パラメータとして受け付けてしまうことがあります。正しい日付を入力パラメータとして指定する限り、問題はありません。
- ODBC 2.5 の次の 2 つの API は 2000 年問題の影響を受けます。SQLInstallDriver と SQLInstallODBC API は ODBC ドライバのセットアップをカスタマイズするために使用されます。次の条件の場合に、不正なバージョンのファイルがインストールされる場合があります。
- SQLInstallDriver と SQLInstallODBC API を使用してセットアップを書いている
- INF ファイルを使用して、インストールするファイルのリストを指定している
- INF ファイルのファイル リストが、ファイルのバージョンでなく、ファイルの日付を含んでいる
Win32 と Win16 API の両方ともこの問題の影響を受けます。注意:SQL Server 6.5 で提供される SQL Server ODBC インストールは日付とバージョン情報の両方を使用するので、影響を受けません。
SQLInstallODBC API は ODBC 2.5 からは提供されていません。SQLInstallDriver はまだ存在しますが、 INF ファイル (問題の原因) を使用するオプションは ODBC 3.0 で削除されました。新規に追加された SQLInstallDriverEx API を推奨しています。
ガイドラインと推奨事項:
- データベース スキーマを調べ、smalldatetime データ型が使用されているかどうか確認します。使用されている場合は、必要に応じて、datetime に変換して精度を上げます。
- 西暦を 4 桁で入力し、アプリケーションで日付や処理できる期間があいまいにならないようにします。
- SQL Server をバックエンドとして、フロントエンド アプリケーションの動作とほかのアプリケーションとのやり取りを調べます。