質問

最初に少し背景を説明します。私の会社は、InformixデータベースをOracle 10gに移行するかどうかを評価しています。 ESQL / Cプログラムがいくつかあります。 Oracle Migration Workbenchをいくつか実行し、いくつかのテストをいじっていました。今、私はいくつかのことに気付きました。

最初に、NULL値をまったく処理しない動的SQLステートメントがあります。私が読んだことから、nvl()関数を利用するためにクエリを手動で変更するか、インジケータ変数を実装する必要があります。手動の変更が必要かどうかを誰かが確認できますか?変換されたESQL / Cプログラムに対して行う必要のある手動の変更は最小限で済みます。

次に、さまざまなテーブルなどから日付を取得するクエリがいくつかあります。Informixの日付はlong型、1899年12月31日からの日数として扱われます。

Pro * Cでは、日付はどの形式として選択されていますか?長い変数に日付フィールドを選択しようとすると、「NUMBERが期待されているがDATE」というOracleエラーが表示されるため、数値ではないことがわかります。したがって、日付フィールドの選択方法を変更する必要があると仮定しています-変換された方法で日付フィールドを選択して長い(つまり、1899年12月31日からの日数)か、ホストを変更するOracleが返しているものと一致する変数(それは文字列ですか?)。

役に立ちましたか?

解決

Oracleの日付(Oracleの内部形式で保存されている)を長整数に変換するには、クエリを変更する必要があります。日付には次の式を使用します。

to_number (to_char (date_column, 'J')) - to_number(to_char(to_date('12/31/1899', 'MM/DD/YYYY'), 'J'))

Oracleシステムの「J」(ユリウス日付)形式は、4712BC 12月31日からの日数のカウントです。後の日付からカウントする場合は、その後の日付のユリウス日カウントを減算する必要があります。

1つの提案:プログラム内のすべてのクエリを変更する代わりに(問題が発生し、バグが発生する可能性があります)、別のスキーマでビューのセットを作成します。これらのビューには、すべてのテーブルと同じ名前が付けられ、すべて同じ列になりますが、NVL()およびdate()数式(上記のように)が含まれます。次に、ベーステーブルスキーマではなく、ビュースキーマをアプリケーションに向けます。テストがはるかに少なくなり、何かを見逃す場所が少なくなります。

たとえば、すべてのテーブルを" APPS_BASE"というスキーマに入れます。 (ユーザー" APPS_BASE"によって定義されます。その後、" APPS_VIEWS"という別のスキーマ/ユーザーを作成します。APPS_VIEWSでビューを作成します。

CREATE OR REPLACE VIEW EMP AS
SELECT name, birth_date
FROM   APPS_BASE.EMP;

他のヒント

はい。説明に従ってクエリを変更する必要があります。

longはあなたをつまずかせます。 longはOracleで異なる意味を持ちます。特定のDATEタイプがあります。一般に、1つを選択するときは、フォーマットを指定したTO_DATE関数を使用して、結果をVARCHAR2として目的のフォーマットで取得します。

おそらくまだヒットしていませんが、Oracleでは空のVARCHAR2フィールドはNULLであることに注意してください。この背後にロジックはありません(おそらくInformixの土地から来たためです)-念頭に置いてください。私はそれが愚かだと思う-私見空の文字列は意味があり、NULLとは異なります。

すべてのVARCHAR2フィールドを NOT NULL DEFAULT '-' または他の任意の値に変更するか、VARCHAR2フィールドを返すすべてのクエリでインジケータを使用するか、常に NVL( )

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top