移行における問題

InterBase XE7 の移行に関わる問題

古いクライアント（古い IBConsole）が、新しい ODS 16 データベースに接続しようとすると、例外が発生する点に注意してください。これは、そのクライアントが INTEGER として定義されていないデータ型に直面するためです。回避策は、新たな IBConsole をインストールして、新旧の InterBase サーバーに接続します。新しい IBConsole は、この用途のために後方互換性があります。

InterBase Lock Table サイズは、IBConfig パラメータを変更して増加させる必要があります。これは、すべてのエントリが領域を取るためです。 InterBase Lock Table サイズを増加させるには、ibconfig ファイルを編集して、V4_LOCK_MEM_SIZE エントリを変更してください。

InterBase XE7 は、ODS 16 と共にリリースされています。新しいエンジンは、ODS 13 移行のみをサポートしています。この変更により、サポートされているすべてのプラットフォームは、同じ ODS バージョン（13 から 16）をサポートします。

古いバージョンの Visual Studio（2005 以前）で構築されている 64 ビット UDF ライブラリは、InterBase XE7 で動作しないというレポートが上がっています。古い UDF ライブラリがある場合、新しい InterBase バージョンで念のためテストしてください。もしくは、UDF 64 ビットライブラリを最新バージョンの Visual Studio で再ビルドしてください。

新しいキーワード ROW が、SQL キーワードトークンとして「予約語」になりました。

InterBase XE3 の移行に関わる問題

Windows レジストリおよびプログラムファイルの変更

InterBase XE3 では、よりよい Windows 互換性のために変更が行われています。 InterBase XE3 では、[Program Files] の場所への製品のインストールがデフォルトになり、Windows レジストリ階層でも「Borland」サブキーを使用しなくなりました。現在では、インスタンス固有の情報の追跡には、「Embarcadero」サブキーを使用しています。お使いのアプリケーションを、なるべく早く新しい環境へ移行することを、強くお勧めします。

プログラムファイルのインストール場所
2009 以降のバージョンの InterBase は、製品を Windows のデフォルトフォルダ [Program Files] 以下の場所へインストールされていました。これは、Windows UAC ガイドラインによるもので、管理者権限のないアプリケーション周りには制限をおき、[Program Files] ファイルシステムフォルダ下への書き込みを抑制しています。 InterBase XE3 でのサーバーベースエディションでは、Windows アプリケーション互換性ガイドラインに準拠し、デフォルトインストール場所が、C:\Embarcadero\InterBase から C:\Program Files\Embarcadero\InterBase へ変更されました。

プログラムデータの場所
InterBase XE3 では、プログラムデータファイルを、%ALLUSERSPROFILE%\Embarcadero\InterBase ディレクトリに配置するようになりました。インストールの各インスタンスについて、この下にフォルダが作成され、書き込みアクセスを必要とするすべてのファイルが、ここに配置されます。たとえば、InterBase XE3 をデフォルトでインストールした場合、「gds_db」インスタンスを取得し、InterBase の書き込み場所とファイルは次のようになります：
- ディレクトリ： %ALLUSERSPROFILE%\Embarcadero\InterBase\gds_db
- ファイル：
  - admin.ib （古いバージョンの InterBase から移行している場合には、ここに古い admin.ib ファイルを配置する）
  - license/ （ここに InterBase ライセンスファイルを配置する）
  - examples のサブフォルダ構造と、すべての関連ファイル
  - OTW SSL 関連ファイルは、「secure」サブフォルダに
  - 実行時作成されるファイル（interbase.log、*.lck、*.env など）

InterBase XE 以前の移行に関わる問題

旧バージョンをアンインストールする前に、セキュリティデータベースを含むすべてのデータベースを必ずバックアップしてください。
SUSE 11 SP1（もしくはそれ以降）のサーバーを対象と考えているのなら、InterBase クライアントを 10.0.0.292 以上にアップグレードすることをお薦めします。 SUSE 11 SP1 サーバーからのイベントを待機する、古いバージョンのクライアントには、既知の問題があります。
カスタマイズされている場合は、ibconfig をバックアップします。
このバージョンでは、新しいデータベースは ODS バージョン 15 で作成されます。
64 ビット版の InterBase では、64 ビット UDF ライブラリだけを使用してください。 64 ビットサーバーでは、これまでの 32 ビット UDF ライブラリを読み込めません。提供されている UDF ライブラリ（OOTB、ib_udf）は、既に 64 ビット用にビルドされており、製品と一緒にインストールされています。
InterBase XE では、1 つのテーブルに格納できるレコード数が増えています。現在のカウントには 32 ビットという限界があります。 32 ビットよりも大きいレコード値の数のカウントが必要であれば、以下の手順を実行してください。
- テーブルの行数が 2 G を超える場合には、CAST(COUNT(*) AS NUMERIC(18,0)) というコードを使用してカウントを 64 ビットにしなければなりません。
InterBase XE で、強度の高いパスワード保護が実装されました。古いバージョンの InterBase クライアントが（ローカルまたはリモートシステムから）このインストールファイルと通信する場合には、システムを InterBase XE3 にアップグレードする際に、次の点に留意してください。
- 既存の（旧バージョンの InterBase で使用していた）ユーザー認証データベースがある場合には、そのデータベースファイルを（InterBase XE フォルダにコピーして）使用すると、ローカルやリモートのクライアントの認証は正しく動作します。
- InterBase XE の新しい admin.ib を使用する場合には、このデータベースで強度の高い "SHA-1" パスワード（デフォルト）が使われていることに注意してください。強度の低い DES パスワードアルゴリズム（これまでの InterBase リリースのもの）を引き続き使用する場合には、「強度の高いパスワード保護」のトピックで説明した ALTER DATABASE コマンドを使用してください。
- InterBase XE で提供されている "強度の高い長いパスワード" を使用する場合には、ユーザーアカウントを作り直し、かつ、この InterBase XE サーバーに接続しているリモートマシンに新しい InterBase クライアントをインストールする必要があります。これは、"古い" InterBase クライアントでは "SHA-1" パスワードを計算することができず、"DES" の強度のパスワードを渡すので、InterBase XE サーバー側で予期しているものと一致しないためです。その結果、"Your user name and password are not defined...（ユーザー名とパスワードが定義されていません）" というエラーが出力されます。
InterBase XE の更新された SSL パラメータ名。古い OTW クライアントプロパティは、新しい OTW プロパティによって置き換えられました。『操作ガイド』の「OTW 暗号の設定」および、第 5 章にある表 5.2 を参照してください。

データベースを復元すると "unassigned code（割り当てられていないコード）" というエラーが出力される

InterBase XE でデータベースを復元すると、"unassigned code（割り当てられていないコード）" というエラーが出力されます。長く使われているデータベースや、InterBase 2009 でバックアップして InterBase XE で復元したデータベースでは、メタデータセキュリティの設定が異なります。そのため、システムテーブル（RDB$RELATIONS など）に対して SELECT 文を実行すると、次のエラーメッセージが出力されます： "no permission for read/select access to table RDB$RELATIONS by user SYSDBA" （ユーザー SYSDBA は RDB$RELATIONS の読み取り/検索アクセスを行う権限がありません）

このエラーは、次の基準に当てはまるデータベースで発生します。

元々は InterBase 6.5 より前のバージョンで作成された。
InterBase 2009 より前のバージョンでバックアップされた。
Readmeta.sql がまだ適用されていない。

このような動作が生じるのは、データベースの復元を行うときに、InterBase XE ではメタデータ権限が厳密に適用されるためです。

解決方法：

この問題を解決するには、バックアップする前に readmeta.sql をデータベースに対して実行します。 readmeta.sql は、多くの場合、\examples\security にあります。 isql または IBConsole を使用して、readmeta.sql をデータベースに対して実行することができます。

説明：

長い間使われているデータベースでこの問題が発生します。（1）データベースが IB6 -> IB7 -> IB2007 -> IB2009 -> IBXE と復元されてきた、（2）データベースが IB2009 でバックアップされて IBXE で復元された、という 2 つの状況が考えられます。それぞれの状況で、メタデータセキュリティ設定は異なります。（1）の場合は、最初に IB6 で作成されているため、そもそもメタデータセキュリティが設定されていません。それに対して（2）の場合には、IB2009 で作成されているため（復元はされていません）、すべてのシステムテーブルにあらゆるセキュリティ権限が設定されています。

前者の場合、データベースはバックアップと復元が繰り返され、新しいリリースになるたびに、そのリリースで追加されたシステムテーブル（RDB$USERS、RDB$ENCRYPTIONS、RDB$ROLES など）の権限が設定されます。ただし、元々存在するシステムテーブルについては、データベース所有者が既にセキュリティ権限を変更しているかどうかを判断できないため、変更は行われません。たとえば、ユーザーが RDB$TRIGGERS および RDB$PROCEDURES に対する権限をすべて取り消して、トリガーやストアドプロシージャのコードを隠していることも考えられます。

また、前者の場合には、何年も前に SYSDBA が readmeta.sql を実行し、その基準のメタデータを変更してカスタムセキュリティプロファイルを作成している可能性もあります。 XE の復元の後で InterBase が自動的に既定値に戻して、そのカスタマイズを上書きすることはできません。 InterBase XE では、個々のデータベースのこれまでの履歴を把握していないため、復元するすべてのデータベースに無条件にデフォルトのメタデータ権限を設定するべきだと想定することはできません。

そのため、readmeta.sql を実行し、そのデフォルト値を出発点として望ましい状態に構成することをお勧めします。これは、移行先が XE 以外の場合でも同じです。

isql の使用例：

isql "path to database" 
-user sysdba -password masterkey -i readmeta.sql

IBConsole での readmeta.sql の実行

IBConsole でデータベースに接続します。
[ツール｜対話型 SQL...] を選択します。
[クエリー｜SQL スクリプトの読み込み] を選択し、readmeta.sql を選択して [開く] をクリックします。

ERROR: No Permission for read/select access to table RDB$XXXX by user SYSDBA（ユーザー SYSDBA はテーブル RDB$XXXX の読み取り/検索アクセスを行う権限がありません）

InterBase 6.5 より前のバージョンで作成されたデータベースでは次のエラーを発生させる可能性があります： no permission for read/select access to table RDB$XXXX by user SYSDBA with InterBase XE. （ユーザー SYSDBA は InterBase XE でテーブル RDB$XXXX の読み取り/検索アクセスを行う権限がありません）

解決方法：

InterBase XE ではメタデータのセキュリティが厳しくなっているため、バージョン 6.5 よりも前の InterBase で最初に作成されたデータベースに対してメタデータ操作を行うと、このエラーが出力される可能性があります。メタデータ操作には、システムオブジェクトの一覧の作成などシステムオブジェクトの情報を要求する、それを更新する、パフォーマンスモニタを使用する、といったものがあります。

このエラーを解決するには、よく似た 2 つの操作を実行する必要があります。最初の操作では、システムテーブルに対する権限を付与します。そのためには、InterBase インストールディレクトリの examples\security フォルダにある readmeta.sql を実行します。isql または IBConsole を使用して、readmeta.sql をデータベースに対して実行することができます。

isql の使用例：

isql "path to database" 
-user sysdba -password masterkey -i readmeta.sql

IBConsole での readmeta.sql の実行

IBConsole でデータベースに接続します。
[ツール｜対話型 SQL...] を選択します。
[クエリー｜SQL スクリプトの読み込み] を選択し、readmeta.sql を選択して [開く] をクリックします。

次に、パフォーマンス監視機能を使用する場合には、システム一時テーブルに対する権限を付与する必要があります。セキュリティ上の問題が起きる可能性があるため、ほとんどのインストールでは、システム一時テーブルに対する権限を sysdba およびデータベース所有者にしか付与しないようになっています（以下で紹介しているのはそれです）。すべてのユーザーがシステム一時テーブルを閲覧できるようにするには、この例を GRANT TO PUBLIC に変更してください。特定のユーザーだけに権限を付与したい場合もあるでしょう。そのときにはさらにカスタマイズされたスクリプトが必要になる可能性があります。

システム一時テーブルに対する権限を付与するには、以下のコードをテキストファイルに保存し、上記の readmeta.sql と同様に実行してください。

create procedure granttmp as
   declare variable stmt varchar(1024);
   declare variable ownername varchar(66);
   declare variable tablename varchar(66);
 begin
   select rdb$owner_name from rdb$relations where rdb$relation_name = 'RDB$RELATIONS'
   into :ownername;
 For select rdb$relation_name from rdb$relations where rdb$system_flag&gt;0 and rdb$relation_name 
 starts with 'TMP$' into :tablename 
 do 
 begin
   stmt = 'grant all on ' || tablename || ' to sysdba';
   execute statement stmt;
   stmt = 'grant all on ' || tablename || ' to ' || ownername;
   execute statement stmt;
 end
 end;
 execute procedure granttmp;
 drop procedure granttemp;
 commit;
 exit;

移行における問題

目次

InterBase XE7 の移行に関わる問題

InterBase XE3 の移行に関わる問題

Windows レジストリおよびプログラムファイルの変更

InterBase XE 以前の移行に関わる問題

案内メニュー

個人用ツール

名前空間

変種

表示

その他

検索

InterBase XE7

デモ & チュートリアル

以前のリリース:

ツール

移行における問題

目次

InterBase XE7 の移行に関わる問題

InterBase XE3 の移行に関わる問題

Windows レジストリおよびプログラム ファイルの変更

InterBase XE 以前の移行に関わる問題

案内メニュー

検索

Windows レジストリおよびプログラムファイルの変更