簡単な答えは、6iから10gへの移行を確認するように指示することです。 。
以前にそれを行ったことがあるので、はるかに有用な答えは、それらのフォームとレポートを最初から書き直すように指示することだと思います。おそらく別のツールで-特に、古代のJavaランタイムに邪魔されるのではなく、Webインターフェイスなどが必要な場合。
古いフォームコードをPL/SQLに変換できる製品があります。 クマラン はその一例ですが、バグがあり、元のコードと同じように機能させるには、コードを手作業で編集する必要がありました。
私に関する限り、CUIは機能していないので、GUIまでたどり着いたほうがよいでしょう。前回見たときは、CUIフォームのドキュメントがほとんどなく、GUIで機能するものがCUIでまったく機能しないことがよくありました。
CUIベースのフォームアプリケーションをGUIに変換する際に遭遇する可能性のある問題がいくつかあります。
-
ユーザーが次または前のフィールド/ブロックなどに移動すると、検証と特別な処理が行われることがあります。適切なGUIに切り替えると、ユーザーは別のフィールドをクリックするだけでこれらのイベントをスキップできます。したがって、2つの選択肢があります。＃1すべてのフォームを監査するか、＃2マウスを使用してフォーム内のナビゲーションを無効にする
オプション＃1は再開発よりも手間がかかりませんが、すでにどれだけの作業を行っているかを確認してください。
オプション＃2ユーザーはあなたを嫌い、熊手と松明であなたを追いかけます。彼らは、あなたがそれに費やしたすべての仕事に対して何の価値もないことを認識するでしょう。そうすれば、とにかくオプション＃1を実行することになります。
-
CUIで正常に機能する（またはCUIの制限によって必要とされる）UIは、まったく間違っており、ユーザーがGUIの他の部分での作業に慣れているUIメタファー（リスト付きのポップアップウィンドウなど）を壊してしまうことがあります。正しい値を直接選択できる場所をプルダウンするのではなく、エントリを選択する必要があること）
-
GUIに変換すると、CUIは、新しく作成したフォームとは異なるフォント、テキストサイズ、およびその他のフォーマットのデフォルトになる可能性があります（私にとってはそうです）。そのため、フォーム/レポートのOracleの新しいデフォルトのテーマに従うようにフォームのセット全体を更新するか、すべての新しいフォーム/レポートを以前の不格好なスタイルに戻す必要があります。そうしないと、親指のように突き出てしまいます。 （そして、ユーザーはそれらすべてが今ではきれいなもののようになりたいと思うでしょう）。
あなたが望んでいた答えではありません。は。ただし、これを言い訳として使用して、Forms / Reportsアップグレードトレッドミルから抜け出し、何年にもわたって発生しなければならなかったハッキングの一部をクリーンアップすることもできます。