| Oracle® Database SQLJ開発者ガイド 11g リリース2 (11.2) B56282-02 |
|
 前 |
 次 |
この章では、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操作をサポートする拡張機能もあります(これは事前定義されていないため、操作をリアルタイムに変更できます)。また、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規格の機能を使用するには、Java2 Platform, Enterprise Edition(J2EE)に準拠したJava Development Kit(JDK)1.5.x以上の環境が必要です。SQLJトランスレータでは、ISO SQLJ規格の仕様より広範なSQL構文を使用できます。
|
注意: Oracle SQLJ実装はJDK 1.5.xでのみサポートされています。 |
ISO SQLJ規格は、SQLのSQL-92エントリ・レベル言語に対応していますが、それを超える拡張にも対応しています。Oracle SQLJ実装では、OracleのSQL言語、つまりSQL-92エントリ・レベルのスーパーセットを使用できます。他のデータベースと連携するSQLJプログラムを作成する場合は、他の環境でサポートされない場合があるため、SQL-92エントリ・レベル以外の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クラス宣言、およびSQL文が埋め込まれたSQLJ実行文が混在して含まれています。SQLJソース・ファイルのファイル名拡張子は.sqljです。このファイル名は有効なJava識別子である必要があります。ソース・ファイルでPublicクラスを宣言する場合、ファイル名はこのクラスの名前と一致する必要があります。ソース・ファイルでPublicクラスを宣言しない場合、ファイル名は、最初に定義したクラスの名前と一致させる必要があります。
ここでは、次の項目について説明します。
.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ホスト変数の間の型の不一致がないか探します。ホスト変数は、SQL操作で入力または出力パラメータとして使用されるJavaローカル変数です。
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構文を使用して、getEmployeeAddress()に渡された番号(empno)が従業員番号に一致する場合に、従業員の住所をemployee表から選択します。これには、データを受け取る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 Microsystemsから提供されたJavaプラグインを使用する方法があります。詳細は、次を参照してください。
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 SQLJ標準コード生成の場合は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オプションおよびOracle固有のコード生成をサポートしていません。ISO SQLJ標準コードをサーバーで使用するには、クライアント上で変換して、個々のコンポーネントをサーバーにロードする必要があります。また、異なる設定で生成されたコードを実行するときには、相互運用性に関する制限事項に留意してください。詳細は、「クライアント側での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プログラミング用のJavaベースのクロス・プラットフォーム・ビジュアル開発環境です。開発者はJDeveloperで、スケーラブルな複数層インターネット・アプリケーションを構築し、Oracle Internet Platform全体でJavaを使用できます。この製品(JDeveloper IDE)では、コンポーネントベースのアプリケーションを作成、デバッグおよびデプロイできます。
Oracle JDBC OCIおよびThinドライバは、JDeveloperに含まれています。JDeveloperのコンパイル機能には、統合されたSQLJトランスレータが含まれており、SQLJアプリケーションがコンパイル時に自動的に変換されるようになっています。
JDeveloperに関する情報は、次のURLから閲覧できます。
UNIX環境ではなくMicrosoft Windows環境を使用する場合は、次の点に注意してください。
このマニュアルでは、UNIX構文を使用しています。JVMではプラットフォーム固有の形式のファイル名およびパスが求められるため、プラットフォームに適した、プラットフォーム固有のファイル名およびディレクトリ・セパレータ(Microsoft Windowsでは「\」など)を使用してください。これは、異なるファイル名構文が許可されるシェル(kshなど)を使用する場合でも同様です。
UNIXの場合は、Oracle SQLJ実装のフロントエンド・スクリプトsqljを使用して、SQLJトランスレータを起動できます。Microsoft Windowsでは、かわりに、Oracleの実行可能ファイルsqlj.exeを使用します。Microsoft Windowsの.batファイルでは、引数への等号(=)の埋込み、引数の文字列操作およびファイル名引数でのワイルドカード文字の使用がサポートされていないため、Microsoft Windowsではスクリプトを使用できません。
環境変数の設定方法は、オペレーティング・システムによって異なります。OS固有の制限事項がある場合もあります。Windows 95では、「システム」コントロール・パネルの「環境」タブを使用します。また、Windows 95では変数設定で「=」文字を使用できないため、SQLJではSQLJ_OPTIONS(SQLJがオプション設定に使用できる環境変数)の設定に、「=」ではなく「#」を使用できます。環境変数の設定および構文についてはオペレーティング・システムのマニュアルを参照し、サイズ上の制限に注意してください。
どのようなオペレーティング・システムおよび環境を使用している場合も同様ですが、特定の制限事項には留意してください。特に、展開された完全なSQLJコマンドラインのサイズが、許容されるコマンドラインのサイズの最大値を超えないようにしてください。Windows 95の場合は250文字以内、Windows NTの場合は4000文字以内にします。使用するオペレーティング・システムのドキュメントを参照してください。
詳細は、Windowsのリリース・ノートを参照してください。
