| Oracle Database SQLJ開発者ガイドおよびリファレンス 11g リリース1（11.1） E05723-01 |
|
 戻る |
 次へ |
この章では、SQLJの機能と使用例について概要を説明します。次の項目について説明します。
SQLJの基本概念を紹介し、Oracle DatabaseアプリケーションにおけるJavaとPL/SQLとの間の相補的な関係を説明します。
SQLJを使用したアプリケーション・プログラミングでは、Javaの設計思想に基づいて、Javaコード中にSQL文の埋込みが可能です。SQLJプログラムとは、SQL文が埋め込まれたJavaプログラムのことで、国際標準化機構（ISO）規格のSQLJ言語リファレンス構文に準拠しています。Oracle SQLJ実装では、ISOのSQLJ標準仕様がサポートされています。標準仕様には、静的SQL操作のみが含まれます。静的SQL操作は事前定義され、ユーザーによるアプリケーションの実行中にリアルタイムで変更されることはありません。Oracle SQLJ実装には、動的SQL操作をサポートする拡張機能もあります。動的SQL操作は事前定義されていないため、操作をリアルタイムに変更できます。SQLJアプリケーション内のJava Database Connectivity（JDBC）コードまたはPL/SQLコードを介して動的SQL操作を使用することも可能です。通常のアプリケーションには、動的SQL操作より静的SQL操作が多く含まれています。
SQLJは、トランスレータとランタイム・コンポーネントで構成され、開発環境にスムーズに統合できます。sqljフロントエンド・ユーティリティを使用すると、トランスレータを実行して、コードの変換、コンパイルおよびカスタマイズを1つの手順で実行できます。変換処理では、埋込みSQL文が、そのSQL文を処理するSQLJランタイムのコールに置き換えられます。ISO標準SQLJでは、このための手段として、通常、JDBCドライバのコールが使用されます（必須ではありません）。Oracle Databaseにアクセスするには、通常、Oracle JDBCドライバを使用します。SQLJアプリケーションを実行すると、SQL操作を処理できるようにSQLJランタイムが起動します。
SQLJトランスレータは、Oracleの他のプリコンパイラと概念的には同様です。トランスレータを使用すると、SQL構文のチェック、SQL操作がスキーマで使用可能かどうかの検証およびJava型と対応するデータベース型との互換性のチェックを行うことができます。これによって、ユーザーの実行時にエラーになるのではなく、開発時にエラーを検出できます。トランスレータは次のチェックを行います。
埋込みSQL文の構文をチェックします。
SQL構文と所定のデータベース・スキーマとを照合し、特定のSQLエンティティ内の整合性を（必要に応じて）確認します。
具体的には、表や列の名前などを検証します。
JavaとSQL間で変換されるデータのデータ型に互換性があることを確認し、型変換が適切に行われるようにするため、データ型をチェックします。
SQLJ文をJavaコードに直接埋め込むSQLJ方式は、扱いやすく簡潔で、データベース接続を必要とするJavaプログラムの開発費とメンテナンス費を節約できます。
一方、Javaプログラムの場合、JDBCまたはSQLJを使用することにより、PL/SQLストアド・プロシージャおよび無名ブロックのコールが可能となります。特にSQLJでは、SQLJ文の内部からストアド・プロシージャおよびファンクションをコールしたり、SQLJ文中に無名PL/SQLブロック埋込みも可能です。
|
注意: SQLJ文内で無名PL/SQLブロックを使用すると、SQLJアプリケーション内で動的SQL操作をサポートできます。ただし、Oracle SQLJ実装には、動的SQL操作を直接サポートする拡張機能があります。 |
この項では、Oracle SQLJ実装の2つの主要なSQLJコンポーネントについて説明します。次の項目について説明します。
このコンポーネントは、SQLJソース・コードの作成後に実行するプリコンパイラです。
トランスレータはPure Javaで書かれており、SQL文をSQLJ実行文に埋め込むためのプログラミング構文をサポートします。SQLJ実行可能文およびSQLJ宣言は、先頭に#sqlトークンが付き、SQLJソース・コード・ファイル内ではJava文と混在できます。SQLJソース・コード・ファイルの拡張子は、必ず.sqljにします。次に、SQLJ文の例を示します。
#sql { INSERT INTO emp (ename, sal) VALUES ('Joe', 43000) };
トランスレータによって.javaファイルが生成されます。
sqljコマンドライン・ユーティリティを使用して、トランスレータを起動できます。コマンドラインで、変換が必要なファイルおよび必要なすべてのSQLJオプション設定を指定します。
Oracle SQLJ実装では、ISOのSQLJ仕様がサポートされています。ISO SQLJ規格は米国規格協会（ANSI）SQLJ規格のスーパーセットであるため、Java2 Platform, Enterprise Edition（J2EE）でコンパイルするJava Development Kit（JDK）1.5以上の環境を必要とします。SQLJトランスレータでは、ANSI SQLJ規格の仕様よりも広範なSQL構文を使用できます。
|
注意: Oracle SQLJ実装はJDK 1.5.xでのみサポートされています。 |
ANSI規格は、SQLのSQL92言語に対応していますが、それを超える拡張にも対応しています。Oracle SQLJ実装では、OracleのSQL言語、つまりSQL92のスーパーセットを使用できます。他のデータベースと連携するSQLJプログラムを作成する場合は、他の環境でサポートされない場合があるため、ANSI SQLJ規格以外のSQL構文とSQL型の使用を避ける必要があります。
ここでは、次の項目について説明します。
Oracle SQLJ実装では、次のJava型がSQLJ規格の拡張としてサポートされます。
oracle.sql.*クラスのインスタンス。SQLデータのラッパーとして使用します。
カスタムJavaクラス。通常、JPublisherユーティリティで生成し、SQLオブジェクト、オブジェクト参照およびコレクションに対応付けます。たとえば、oracle.sql.ORADataインタフェースやJDBC標準java.sql.SQLdataインタフェースを実装するクラスがあります。
|
注意: SQLDataインタフェースが標準です。このインタフェースを実装するクラスは、JDBCドライバおよび他のベンダーのデータベースでもサポートされています。 |
ストリームのインスタンス（BinaryStreamおよびCharacterStream）。後者は現在使用されていないAsciiStreamおよびUnicodeStreamにかわるものです。出力パラメータとして使用します。
イテレータと結果セットのインスタンス。入力または出力パラメータとして使用されます。SQLJ規格では、結果式またはキャスト文での使用のみを規定しています。
Unicodeキャラクタ型（NString、NCHAR、NCLOBおよびNcharCharacterStream）。NcharCharacterStreamは、現在使用されていないNcharAsciiStreamおよびNcharUnicodeStreamにかわるものです。
これらの拡張要素のいずれかを使用した場合、変換時にOracle固有コード生成またはOracleのカスタマイズが必要になる他、アプリケーション実行時にOracle SQLJランタイムおよびOracle JDBCドライバも必要になります。自作コードが他の環境で使用される場合は、拡張型を使用しないでください。アプリケーションの移植性を確認するには、SQLJの-warn=portableフラグを使用します。
Oracle SQLJ実装では、次の拡張機能もサポートされています。
Oracle固有コード生成
これによって、JDBCコードが直接生成されます。プログラムの実行中、SQLJランタイム機能の多くは無視されます。
SQLJ文中の動的SQL
付加的なナビゲーション・メソッドによるスクロール可能な結果セット・イテレータ、および結果セット・イテレータやスクロール可能な結果セット・イテレータからのFETCH構文
列定義とパラメータ・サイズ定義の最適化フラグ
変更された変換動作のフラグ。識別子によってホスト式をバインドし、WHERE句のCHAR比較で空白埋めを考慮します。
接続コンテキストでのSQLJ文のキャッシング
SQLJソース・コードの内容は、標準Javaソース・コードとSQLJクラス宣言およびSQLJ実行文です。SQLJ実行文にはSQL文が埋め込まれています。SQLJソース・ファイルの拡張子は.sqljです。ファイル名は、必ず該当のJava識別子にします。ソース・ファイルでPublicクラスを宣言している場合は、このクラスの名前をファイル名にする必要があります。ソース・ファイルにPublicクラスが宣言されていない場合は、1番目に定義されているクラスと同じ名前をファイル名に付けてください。
ここでは、次の項目について説明します。
.sqljファイルを記述した後、SQLJを実行してファイルを処理します。次の例では、PublicクラスがFooであるFoo.sqljソース・ファイルに対して、SQLJを実行します。ここでは、コマンドライン・オプションを指定しない最も単純な方法で実行します。
% sqlj Foo.sqlj
このコマンドを実行すると、プラットフォームに応じて、フロントエンドのスクリプトまたはユーティリティが実行されます。このスクリプトまたはユーティリティは、コマンドラインを読み込み、Java Virtual Machine（JVM）を起動し、引数をこのJVMに渡します。JVMはSQLJトランスレータを起動し、フロントエンドとして機能します。
以降の処理は、次の順に展開されます（各手順でエラーが発生しなかった場合を想定しています）。
JVMでSQLJトランスレータを起動します。
トランスレータが.sqljファイル内のSQLJおよびJavaコードを解析します。SQLJ構文が検証され、宣言したSQLデータ型とそのJavaホスト変数の型の不一致が検出されます。ホスト変数はJavaのローカル変数であり、SQL操作の入力パラメータまたは出力パラメータとして使用します。
SQLJのオプション設定に従って、トランスレータがオンライン・セマンティクス・チェッカまたはオフライン・パーサー（あるいはその両方）を起動します。これによって、埋込みSQL文やPL/SQL文の構文が検証され、オンライン・チェックの場合はコード内のデータベース要素の使用が該当データベース・スキーマと照合してチェックされます。いずれのオプションも指定されていない場合でも、基本的なレベルのチェックは実行されます。
オンライン・チェックを指定すると、SQLJでは指定したデータベース・スキーマへの接続後に、アプリケーションで使用しているデータベース表、ストアド・プロシージャおよびSQL構文がすべてサポートされているかどうかが検証されます。また、SQLJアプリケーション内のホスト変数の型と対応するデータベース列のデータ型の互換性も検証されます。
Oracle固有のSQLJコード生成（デフォルトの-codegen=oracle）の場合は、SQL操作がOracle JDBCコールに直接変換されます。
生成されたJavaコードは.java出力ファイルに保存されます。次の内容がこのファイルに出力されます。
.sqljソース・ファイル内のクラス定義とJavaコード。
SQLJイテレータおよび接続コンテキストの宣言に基づいて生成されたクラス定義。
Oracle JDBCドライバへのコール。埋込みSQL操作のアクションを実装します。
JVMがJavaコンパイラを起動します。通常、このコンパイラはSun社のJDKで提供される標準javacです。
手順4で生成されたJavaソース・ファイルがコンパイルされ、Javaの.classファイルが生成されます。これには、定義した各クラス（各SQLJ宣言）に.classファイルが含まれます。
SQLJの一般的な注意
SQLJアプリケーションを変換および実行する場合は、次の点を考慮してください。
コマンドラインで、コンパイルされ、型変換が可能でもある既存の.javaファイルを指定することもできます。
アプリケーションの実行時には、コードでOracle固有の機能を使用しない場合にも、Oracle JDBCドライバが必要になります。
ここでは、SQLJトランスレータへの入力として扱われるもの、出力となるものおよびその出力先について、概要を説明します。ここでは、次の項目について説明します。
|
注意: この説明では、イテレータ・クラスと接続コンテキスト・クラスの宣言を扱います。イテレータはJDBCの結果セットに似ています。接続コンテキストはデータベース接続で使用します。 |
SQLJトランスレータは、入力として1つ以上の.sqljソース・ファイルをとります。このソース・ファイルはコマンドラインで指定できます。メインの.sqljファイルの名前は、定義されているPublicクラスまたは定義されている最初のクラス（ある場合）に基づきます。
メインの.sqljファイルでクラスMyClassを定義した場合は、ソース・ファイル名を次の名前にします。
MyClass.sqlj
Publicクラスが未定義でも、最初に定義したクラスの名前がMyClassであれば、ソース・ファイル名をこの名前にする必要があります。各Publicクラスは、別々の.sqljファイルに定義する必要があります。SQLJを実行するときは、複数のSQLJオプションをコマンドラインでもプロパティ・ファイルでも指定できます。
変換処理では、ソース・コードでSQLJ実行可能文を使用する場合、アプリケーション内の.sqljファイルごとにJavaソース・ファイルが生成されます。
SQLJでは、次のJavaソース・ファイルが生成されます。
Javaソース・ファイル。.sqljファイルと同じベース名の.javaファイルです。
たとえば、トランスレータによって、MyClassクラスを定義するMyClass.sqljに対応するMyClass.javaが生成されます。出力.javaファイルには、.sqljファイルで宣言したイテレータまたは接続コンテキスト・クラスのクラス定義も含まれています。
コンパイル処理によって、Javaソース・ファイルが複数のクラス・ファイルにコンパイルされます。.sqljソース・ファイルに定義されたクラスごとに、1つの.classファイルが生成されます。SQLJのイテレータまたは接続コンテキストを宣言した場合は、さらに.classファイルが生成されます。また、コード中に内部クラスまたは無名クラスが宣言されていれば、それらの各クラスごとに.classファイルが個別に生成されます。
これらの.classファイルには、次の名前が付けられます。
定義する各クラスのクラス・ファイル名は、クラス名および.class拡張子から構成されます。たとえば、トランスレータ出力ファイルMyClass.javaは、MyClass.classクラス・ファイルにコンパイルされます。
トランスレータを実行すると、イテレータ・クラスと接続コンテキスト・クラスに、宣言内容に応じた名前が付けられます。たとえば、イテレータMyIterを宣言すると、コンパイラは対応するMyIter.classクラス・ファイルを生成します。
デフォルトでは、生成された.javaファイルが.sqljファイルと同じディレクトリに出力されます。.javaファイルの出力先を変更するには、SQLJの-dirオプションを使用します。
SQLJのデフォルトの設定では、生成済.classファイルと.serファイルは、生成済.javaファイルと同じディレクトリに出力されます。.classファイルと.serファイルの出力先を変更するには、SQLJの-dオプションを使用します。このオプションの設定値がJavaコンパイラに渡され、.classファイルと.serファイルが同じディレクトリに出力されます。
-dまたは-dirオプションを使用するときは、既存のディレクトリを指定する必要があります。
ここでは、同じサンプル･コードの2つのバージョンを比較します。1つはSQLJで記述され、もう1つはJDBCで記述されています。ここでの目的は、SQLJとJDBCのコーディングでの要件の違いを示すことです。ここでは、次の項目について説明します。
|
注意: ここで使用するSQLJ文と機能の詳細は、このマニュアルの後の方で説明します。しかし、ここにサンプルを掲載することは、SQLJとJDBCを比較対照する上での一般概念を示すために有用です。SQLJの概念と機能をよく理解したときに、再度このサンプルを確認してもかまいません。 |
このサンプルでは、次のように2つのメソッドを定義します。getEmployeeAddress()は、従業員番号に基づいて表データを取り出し、その番号を持つ従業員の住所を戻します。updateAddress()は、取り出されたアドレスを受け取ってストアド・プロシージャをコールし、更新された住所をデータベースに戻します。
どちらのバージョンのコードも、次の事項を前提としています。
SQLスクリプトが実行され、データベース内にスキーマが作成され、表にデータが取り込まれていること。いずれのバージョンのサンプル・コードも、このスクリプトによって生成されたオブジェクトおよび表を参照しています。
指定された住所を更新するPL/SQLストアド・ファンクションUPDATE_ADDRESS() が存在すること。
Connectionオブジェクト（JDBC用）およびデフォルトの接続コンテキスト（SQLJ用）が、コール元によって生成されていること。
コール元によって、例外処理が行われること。
updateAddress()メソッドに渡される住所の引数（addr）に、NULL値が許容されていること。
|
注意: サンプル・コードのJDBCとSQLJのバージョンは、単なる部分的なサンプルで、単独では実行できません。いずれのサンプルにも、main()メソッドはありません。 |
次は、SQLJバージョンのサンプル・コードです。このコードには、データベースから従業員の住所を取り出し、それを更新し、更新後の住所をデータベースに戻すメソッドが定義されています。
import java.sql.*;
/**
This is what you have to do in SQLJ
**/
public class SimpleDemoSQLJ // line 6
{
//TO DO: make a main that calls this
public Address getEmployeeAddress(int empno) // line 10
throws SQLException
{
Address addr; // line 13
#sql { SELECT office_addr INTO :addr FROM employees
WHERE empnumber = :empno };
return addr;
}
// line 18
public Address updateAddress(Address addr)
throws SQLException
{
#sql addr = { VALUES(UPDATE_ADDRESS(:addr)) }; // line 22
return addr;
}
}
10行目
getEmployeeAddress()メソッドは、明示的なConnectionオブジェクトを必要としません。SQLJでは、アプリケーションで初期設定されているデフォルトの接続コンテキスト・インスタンスを使用できます。
13から15行目
getEmployeeAddress()メソッドは、従業員番号に基づいて従業員の住所を取り出します。標準のSQLJ SELECT INTO構文を使用して、employee表から従業員のアドレスを選択します。その場合、getEmployeeAddress()に渡された従業員番号（empno）と一致した従業員番号を持つ従業員の住所が選択されます。この処理には、データを受け取るAddressオブジェクト（addr）を宣言する必要があります。empnoおよびaddrの各変数は、入力ホスト変数として使用されます。
16行目
getEmployeeAddress()メソッドは、addrオブジェクトを戻り値とします。
19行目
updateAddress()メソッドでも、デフォルトの接続コンテキスト・インスタンスが使用されます。
19から22行目
取り出された住所はupdateAddress()メソッドに渡され、このメソッドからデータベースに渡されます。データベースでその住所が更新され、更新されたデータが戻されます。実際の住所更新処理は、UPDATE_ADDRESS()ストアド・ファンクションによって実行されます。標準のSQLJファンクション・コール構文を使用して、UPDATE_ADDRESS()から戻されたaddr住所オブジェクトを取り出します。
23行目
updateAddress()メソッドは、addrオブジェクトを戻り値とします。
SQLJバージョンのコード固有の特徴
SQLJバージョンのサンプル・コードの次の特徴に注意してください。
明示的な接続は不要です。SQLJでは、アプリケーションで初期設定されているデフォルトの接続コンテキストを使用できます。
データ型のキャストは不要です。
SQLJでは、_SQL_TYPECODE、_SQL_NAMEまたはファクトリ・オブジェクトの知識は不要です。
NULL値データの暗黙的な処理は必要です。
リソースの明示的な管理（たとえば、StatementオブジェクトやResultSetオブジェクトの終了）は不要です。
SQLJではホスト変数の埋込みが必要です。これに対し、JDBCではパラメータ・マーカーが使用されます。
長いSQL文での文字列の連結は不要です。
出力パラメータの登録は不要です。
SQLJ構文はさらに簡略化されています。具体的には、SQLJではSELECT INTO文はサポートされていますが、OBDC形式のエスケープは使用されません。
文のキャッシュは、自分で実装する必要はありません。デフォルトで、SQLJでは自動的に#sql文がキャッシュされます。これによって、getEmployeeAddress()およびupdateAddress()を繰り返してコールする場合などのパフォーマンスが改善します。
JDBCをよく理解していれば、次のJDBCバージョンのサンプル・コードを確認できます。このコードには、データベースから従業員の住所を取り出し、住所を更新した後、データベースに戻すメソッドが定義されています。
|
注意: 必要に応じて、TO DOで始まるコメント行にコードを追加すると、このサンプル・コードの有用性が高くなります。 |
import java.sql.*;
import oracle.jdbc.*;
/**
This is what you have to do in JDBC
**/
public class SimpleDemoJDBC // line 7
{
//TO DO: make a main that calls this
public Address getEmployeeAddress(int empno, Connection conn)
throws SQLException // line 13
{
Address addr;
PreparedStatement pstmt = // line 16
conn.prepareStatement("SELECT office_addr FROM employees" +
" WHERE empnumber = ?");
pstmt.setInt(1, empno);
OracleResultSet rs = (OracleResultSet)pstmt.executeQuery();
rs.next(); // line 21
//TO DO: what if false (result set contains no data)?
addr = (Address)rs.getORAData(1, Address.getORADataFactory());
//TO DO: what if additional rows?
rs.close(); // line 25
pstmt.close();
return addr; // line 27
}
public Address updateAddress(Address addr, Connection conn)
throws SQLException // line 30
{
OracleCallableStatement cstmt = (OracleCallableStatement)
conn.prepareCall("{ ? = call UPDATE_ADDRESS(?) }"); //line 34
cstmt.registerOutParameter(1, Address._SQL_TYPECODE, Address._SQL_NAME);
// line 36
if (addr == null) {
cstmt.setNull(2, Address._SQL_TYPECODE, Address._SQL_NAME);
} else {
cstmt.setORAData(2, addr);
}
cstmt.executeUpdate(); // line 43
addr = (Address)cstmt.getORAData(1, Address.getORADataFactory());
cstmt.close(); // line 45
return addr;
}
}
このマニュアルでは、主にクライアント側SQLJアプリケーションについて説明しています。しかし、次のような例においてもSQLJコードを実行すると便利な場合があります。
アプレットから
サーバー内で（SQLJトランスレータもサーバーで実行できます）
ここでは、次の項目について説明します。
SQLJランタイムはPure Javaであるため、アプレットでもアプリケーションでもSQLJソース・コードを使用できます。ただし、いくつかの考慮事項があります。
|
参照: Oracle JDBCドライバに適用するアプレットに関しては、『Oracle Database JDBC開発者ガイドおよびリファレンス』を参照してください。 |
ここでは、次の項目について説明します。
次に、アプレットでSQLJを使用する際の一般的な考慮事項を示します。
次のSQLJランタイム・パッケージはすべて、アプレットとともにパッケージ化する必要があります。次のパッケージを含めます。
sqlj.runtime sqlj.runtime.ref sqlj.runtime.error
Oracle独自のカスタマイズを行った場合は、次のパッケージも含める必要があります。
oracle.sqlj.runtime oracle.sqlj.runtime.error
これらのパッケージは、Oracleインストールによって、ORACLE_HOME/libディレクトリのランタイム・ライブラリの中の1つに組み込まれています。
データベース接続用のドライバとして、Oracle JDBC ThinドライバなどのPure Java JDBCドライバを指定する必要があります。
アプレット内のSQLJ実行文ごとに、接続コンテキストのインスタンスを明示的に指定する必要があります。2つのSQLJアプレットを1つのブラウザで実行した場合、同じJVMで実行されるのを防ぐために、必ず明示的に指定してください。
デフォルトのトランスレータ設定-codegen=oracleによって、Oracle固有のコードが生成されます。これによって、実行時のJavaリフレクションの使用が削減されるので、異なるブラウザ環境間での移植性が向上します。
エンド・ユーザーがSQLJアプレットを実行したときに、CLASSPATH内のクラスが、アプレットとともにダウンロードされたクラスと競合する可能性があります。これを回避するためには、アプレットを実行する前に、エンド・ユーザー側でCLASSPATHを削除することをお薦めします。
Java環境およびOracle固有の機能の使用に関しては、追加で考慮する事項を次に示します。
SQLJでは、ランタイム環境としてJDK 1.5が必要です。ユーザーは、プラグインなしでは、古いバージョンのJDKを使用してブラウザでSQLJアプレットを実行することはできません。この対処としては、Sun社のプラグインを使用する方法があります。詳細は次のWebサイトを参照してください。
Oracle固有の機能を使用するアプレットでは、Oracle SQLJランタイムを起動する必要があります。 Oracle SQLJランタイムは、oracle.sqlj.*下のSQLJランタイム・ライブラリ・ファイル内のクラスで構成されます。 Oracle SQLJ runtime.jarライブラリでは、Java Reflection API（java.lang.reflect.*）が必要です。大半のブラウザでは、Reflection APIをサポートしていなかったりセキュリティ上の制約があるのに対し、Sun社のJavaプラグインの場合はReflection APIに対するサポートが提供されています。
|
注意: Oracle固有の機能とは、Oracle拡張型（第5章「型のサポート」を参照）を使用すること、およびOracle固有コード生成を必要とする（またはISO標準コード生成の場合はOracle Databaseインスタンスと連携できるようにカスタマイズされたアプリケーションを必要とする）SQLJ機能を使用することを意味します。（たとえば、第4章「基本的な言語機能」で説明されているSET文がこれに該当します。） |
これまで、Internet ExplorerやNetscapeのブラウザに重点を当てて説明してきました。その要約を次に示します。
SQLJとJDBCのバージョンは一致している必要があります。たとえば、SQLJ 9.0.0ランタイムを使用するには、Oracle 9.0.0以前のJDBCドライバを使用する必要があります。
SQLJ文中にオブジェクト型、JDBC 2.0型、REF CURSORまたはCAST文を使用する場合は、次のいずれかに適合している必要があります。
アプレットを変換するときに、デフォルトの-codegen=oracle設定を使用します。
実行するブラウザではJDK 1.5をサポートしていて、リフレクションが許可されていることを確認します。
ブラウザのJavaプラグインを介してアプレットを実行します。
SQLJコードは、クライアント・アプリケーションで使用できるばかりでなく、ターゲットのOracle Databaseのストアド・プロシージャ、ストアド・ファンクションまたはトリガーでも実行できます。サーバー側のアクセスは、サーバー内部で実行されるOracle JDBCドライバを介して発生します。また、Oracle Database 11g （およびそれ以前のバージョン）には埋込みSQLJトランスレータがあるため、サーバー側で使用するSQLJソース・ファイルをサーバーで直接変換することもできます。
次の2点については考慮が必要です。
サーバー側で使用するSQLJコードの作成
ターゲットのOracle Database側で使用するSQLJアプリケーションのコードの記述方法は、クライアント側で使用するコードの記述方法と類似しています。主な相違点は、JDBCの全般的な特性によるものであり、SQLJ固有の特性によるものではありません。大きな相違点は、次のように接続に関するものです。
接続数が1つに限定されること。
コードが実行されるデータベースに接続すること。
接続が暗黙的に行われること（クライアント側とは異なり、明示的に初期化する必要がありません）。
接続を終了できないこと。終了しようとしても無視されます。
この他、サーバー内で接続に使用するJDBCサーバー側ドライバは、自動コミット・モードをサポートしていないことも挙げられます。
|
注意: サーバー側Thinドライバの一部には、あるサーバー内のコードから別のサーバーへ接続できるものがあります。この場合、クライアントのThinドライバを使用した場合と結果は同様で、しかもコードの記述方法も同様です。 詳細は、「Oracle JDBCドライバの概要」を参照してください。 |
サーバー側SQLJコードの変換とロード
コードの変換とコンパイルは、クライアントでもサーバーでも行えます。クライアント側で行った場合は、クラス・ファイルとリソース・ファイルをクライアントからサーバーにロードできます。Oracleのloadjavaユーティリティを使用してクライアントからファイルをロードするか、またはSQLコマンドを使用してサーバーの管理するファイルをロードします。
また、サーバー側の埋込みSQLJトランスレータを使用して変換とロードを1ステップで行う方法もあります。クラス・ファイルまたはリソース・ファイルのかわりにSQLJソース・ファイルをロードすると、変換とコンパイルは自動的に実行されます。通常、loadjavaまたはSQLコマンドは、クラス・ファイルとリソース・ファイルに対して使用することも、ソース・ファイルに対して使用することも可能です。ユーザーの観点からは、.sqljファイルは.javaファイルと同様に扱われ、変換は暗黙的に実行されます。
|
注意: サーバー側トランスレータでは、SQLJ-codegenオプションおよびISO標準コード生成をサポートしていません。ISO標準コードをサーバーで使用するには、クライアント上で変換して、個々のコンポーネントをサーバーにロードする必要があります。また、異なる設定で生成されたコードを実行するときには、相互運用性に関する制限事項に留意してください。詳細は、「クライアント側でのSQLソースの変換とコンポーネントのロード」および「Oracle固有コード生成（プロファイルなし）」を参照してください。 |
このマニュアルの説明は、UNIX環境で英語版コードを手動で作成する場合を想定しています。ただし、SQLJは他のプラットフォームおよび統合開発環境（IDE）でも使用できます。他言語版のグローバリゼーション・サポートもあります。ここでは、次の項目について説明します。
ネイティブ言語および文字のエンコードは、Javaの組込みグローバリゼーション・サポート機能を使用して、Oracle SQLJ実装によってサポートされます。
トランスレータ・メッセージおよびランタイム・メッセージ用の言語とエンコーディング方法は、JVM標準のuser.languageおよびfile.encodingプロパティによって、特定されます。変換時にソース・ファイルを解析および生成するためのエンコーディングは、SQLJの-encodingオプションで指定します。
Oracle SQLJ実装はプログラムAPIを含むため、Oracle JDeveloper 10g などのIDEへ埋め込むことができます。IDEは、フロントエンドのsqljスクリプトと同じように機能し、トランスレータ、セマンティクス・チェッカ、コンパイラおよびカスタマイザ（使用する場合）を起動します。
JDeveloperは、Javaプログラミング用のWindowsベースのビジュアル開発環境です。開発者はJDeveloperで、スケーラブルな複数層インターネット・アプリケーションを構築し、Oracle Internet Platform全体でJavaを使用できます。この製品（JDeveloper IDE）では、コンポーネントベースのアプリケーションを作成、デバッグおよびデプロイできます。
Oracle JDBC OCIドライバとThinドライバは、JDeveloperに同梱されています。JDeveloperのコンパイル機能には、SQLJトランスレータが組み込まれています。SQLJアプリケーションは、コンパイル時に自動的に変換されます。
JDeveloperに関する情報は、次のURLから閲覧できます。
UNIX環境ではなくMicrosoft Windows環境を使用する場合は、次の点に注意してください。
このマニュアルでは、UNIX構文を使用しています。プラットフォーム固有のファイル名とディレクトリ・セパレータ（Microsoft Windowsの「\」など）を使用してください。JVMでは、プラットフォーム固有の形式でファイル名とパスを指定する必要があるためです。異なるファイル名構文を使用できるシェル（kshなど）を使用している場合にも同様です。
UNIXの場合は、Oracle SQLJ実装のフロントエンド・スクリプトsqljを使用して、SQLJトランスレータを起動できます。Microsoft Windowsでは、かわりに、Oracleの実行可能ファイルsqlj.exeを使用します。Microsoft Windowsの.batファイルでは、引数への等号（=）の埋込み、引数の文字列操作およびファイル名引数でのワイルドカード文字の使用がサポートされていないため、Microsoft Windowsではスクリプトを使用できません。
環境変数の設定方法は、オペレーティング・システムにより異なります。オペレーティング・システム固有の制限が伴う場合もあります。Windows 95では、「コントロール パネル」→「システム」→「ハードウェア環境」タブを使用します。また、Windows 95では変数の設定に「=」文字を使用できないため、SQLJ_OPTIONS（SQLJがオプションの設定に使用する環境変数）の設定では「#」をかわりに使用できます。環境変数の設定および構文については、オペレーティング・システムのドキュメントで確認してください。なお、サイズ上の制約には注意してください。
どのようなオペレーティング・システムおよび環境を使用している場合も同様ですが、特定の制限事項には留意してください。特に、展開されたSQLJコマンドラインのサイズが、許容されるコマンドラインのサイズの最大値を超えないようにしてください。たとえば、Windows 95の場合は250文字以内、Windows NTの場合は4000文字以内にします。詳細は、使用するオペレーティング・システムのドキュメントを参照してください。
詳細は、Windowsのリリース・ノートを参照してください。
