機械翻訳について

2.9 SQL Serverのデータベース互換性の問題

SQL ServerおよびOracleデータベースは、一部の領域で異なる方法で機能するため、互換性の問題が発生します。

これらのトピックでは、互換性の問題について説明します。

2.9.1 暗黙的トランザクション(チェーン・モード)

ゲートウェイは、ANSI標準の暗黙的トランザクションをサポートしています。

このモードでは、SQL Serverストアド・プロシージャを記述する必要があります。 暗黙的なトランザクションを実行すると、ゲートウェイはOracleおよびSQL Serverデータベースを更新するトランザクションにOracleの2フェーズ・コミット保護を拡張できます。

2.9.2 列の定義

デフォルトでは、列定義にNULLが指定されていないかぎり、SQL Server表の列にNULL値を含めることはできません。

SQL Serverでは、このデフォルトをオーバーライドするSQL Serverオプションを設定しないかぎり、すべての列にNULL値を含めることはできません。

Oracle表の場合、列定義でNOT NULLが指定されていないかぎり、列にNULL値を使用できます。

2.9.3 命名規則

これらのトピックでは、命名規則の問題について説明します。

2.9.3.1 オブジェクトの命名規則

OracleとSQL Serverでは、異なるデータベース・オブジェクト命名規則が使用されます。

たとえば、各オブジェクト名に使用できる最大文字数は異なる場合があります。 また、一重引用符と二重引用符、大/小文字の区別、および英数字の使用はすべて異なる場合があります。

関連項目:

Oracle DatabaseリファレンスおよびSQL Serverのドキュメント。

2.9.3.2 大文字と小文字の区別

識別子を二重引用符で囲む場合を除き、Oracleデータベースはデフォルトで大文字になります。

たとえば、empというSQL Server表を参照するには、次のように二重引用符で名前を入力します:

SQL> SELECT * FROM "emp"@MSQL;

ただし、OracleアプリケーションからScottが所有するempというSQL Server表を参照するには、次のように入力します:

SQL> SELECT * FROM "Scott"."emp"@MSQL;

empというSQL Server表がSCOTT(表所有者名は大文字)によって所有されている場合、次のように、二重引用符文字なしで所有者名を入力できます:

SQL> SELECT * FROM SCOTT."emp"@MSQL;

または

SQL> SELECT * FROM scott."emp"@MSQL;

Oracleでは、すべてのSQL Serverオブジェクト名を二重引用符で囲み、SQL Serverデータ・ディクショナリに表示されるオブジェクト名に正確な大文字と小文字を使用することをお薦めします。 「データ・ディクショナリ」にリストされている、サポートされているOracleデータ・ディクショナリ表またはビューを参照する場合は、この規則は必要ありません。

これらの規則に従って既存のアプリケーションを変更できない場合は、Oracleでビューを作成し、SQL Server名を正しい大文字と小文字に関連付けます。 たとえば、大文字の名前のみを使用して既存のOracleアプリケーションからSQL Server表empを参照するには、次のビューを定義します:

SQL> CREATE VIEW EMP (EMPNO, ENAME, SAL, HIREDATE)
      AS SELECT "empno", "ename", "sal", "hiredate"
      FROM "emp"@MSQL;

このビューを使用すると、アプリケーションは次のような文を発行できます:

SQL> SELECT EMPNO, ENAME FROM EMP;

ビューの使用は、SQL Serverデータ・ディクショナリで発生したデータ・ディクショナリ情報を複製する回避策です。 対応する表のデータ定義がSQL Serverデータベースで変更されるたびに、Oracleビュー定義を更新する準備をしておく必要があります。

2.9.4 データ型

これらのトピックでは、データ型の問題について説明します。

2.9.4.1 バイナリ・リテラル表記法

Oracle SQLでは、一重引用符で囲まれた16進数を使用して、データ型RAWとして定義されている列に比較または挿入されるリテラル値を表します。

この表記法は、SQL ServerのVARBINARYおよびBINARYデータ型と互換性のある構文には変換されません(0x の後に16進数、一重引用符で囲みます)。

たとえば、次の文はサポートされていません。

SQL> INSERT INTO BINARY_TAB@MSQL VALUES ('0xff')

ここで、BINARY_TABには、VARBINARYまたはBINARYデータ型の列が含まれます。 VARBINARYおよびBINARYデータ型への挿入または更新時にバインド変数を使用します。

2.9.4.2 LONG列を含むバインド変数

ゲートウェイでは、バインド変数を使用したデータ型LONGの列の更新はサポートされていません。

2.9.4.3 データ型変換

SQL Serverは暗黙的な日付変換をサポートしていません。 このような変換は明示的である必要があります。

たとえば、ゲートウェイは次のSELECT文に対してエラーを発行します:

SELECT DATE_COL FROM TEST@MSQL WHERE DATE_COL = "1-JAN-2004";

暗黙的な変換の問題を回避するには、次のように明示的な変換を追加します:

SELECT DATE_COL FROM TEST@MSQL WHERE DATE_COL = TO_DATE("1-JAN-2004")

関連項目:

データ型の制限の詳細は、「データ型変換」を参照してください。

2.9.5 問合せ

これらのトピックでは、問合せの問題について説明します。

2.9.5.1 行選択

SQL Serverは、選択されたすべての行の問合せ条件を評価してから、いずれかの行を返します。

1つ以上の行の評価プロセスでエラーが発生した場合、残りの行が条件を満たしていても、行は返されません。

Oracleは、問合せ条件の行ごとに評価し、評価が成功すると行を返します。 行は、行が評価に失敗するまで返されます。

2.9.5.2 空の文字列

Oracleは、SQL文の空の文字列をNULL値として処理します。 SQL Serverは空の文字列を空の文字列として処理します。

空の文字列を比較する場合、ゲートウェイはリテラルの空の文字列を変換なしでSQL Serverデータベースに渡します。 空の文字列でNULL値を表す場合は、SQL Serverはそのように文を処理せず、空の文字列を使用します。

この問題を回避するには、次の例のように、空の文字列構文ではなくSQL文でNULLまたはIS NULLを使用します:

SELECT * from "emp"@MSQL where "ename" IS NULL;

空の文字列を選択するには:

  • VARCHAR列の場合、ゲートウェイは空の文字列をNULL値としてOracleデータベースに返します。
  • CHAR列の場合、ゲートウェイは列のフル・サイズを戻し、各文字を空白(')として返します。

2.9.5.3 空のバインド変数

VARCHARバインド変数の場合、ゲートウェイは空のバインド変数をSQL ServerデータベースにNULL値として渡します。

2.9.6 ロック

SQL Serverデータベースのロック・モデルは、Oracleモデルと大きく異なります。

ゲートウェイは、基礎となるSQL Serverの動作に依存するため、次の考えられるシナリオは、ゲートウェイを介してSQL ServerにアクセスするOracle applicationsに影響します:

  • 読取りアクセス権によって書込み権限がブロックされる場合があります
  • 書き込みアクセスが読み取りアクセスをブロックする可能性がある
  • 文レベルの読取り一貫性は保証されません

    関連項目:

    SQL Serverのロック・モデルの詳細は、SQL Serverのドキュメントを参照してください。