Visual Foxpro 6 アプリケーションを Visual Foxpro 9 に変換する際に問題はありますか。それともこれは簡単ですか?
プロセス中に気をつけるべき落とし穴はありますか?
Visual Foxpro 6 アプリケーションを Visual Foxpro 9 に変換する際に問題はありますか。それともこれは簡単ですか?
プロセス中に気をつけるべき落とし穴はありますか?
はい...プロジェクトのさまざまな要素に応じて。現在、VFP9 SP1 と VFP9 SP2 の両方でアプリを使用しています (レポート用に HotFix3 を使用)。
古い形式の SQL クエリを使用して VFP9 で実行する場合に発生するいくつかの問題
SET ENGINE BEHAVIOR 70 おそらく 70 にとどまりたいでしょう。8 と 9 の拡張機能のいくつかは、lazy group by 句での初期のクエリで使用された素晴らしいトリックを強制します...関心のあるいくつかの列でのみグループ化する場合は特に、とにかく、常に同じ値を持つことがわかっているルックアップ テーブルに結合する。8 と 9 では、すべての非集計関数によってグループを修飾する必要があります...そのような場合、これらの「定数」列を MAX( SomeField) as SomeField に変更する必要がある場合があります。グループがとにかく ID キーに基づいていた場合、最大値は決して変わりません。
クエリから知られているその他の問題は、SELECT SUM() に関するものでした。クエリを実行し、クエリに一致するレコードがない場合、SUM() 列は NULL として返され、数値を期待していたときに予期しないデータ型が返されます。簡単な方法の 1 つは、常に COUNT(*) を ActualRecords として追加することでした。これは常に数値を返します。次に、「Result.ActualRecords = 0」がユーザーに通知するかどうか、レポートを中止するかどうか、または続行するかどうかを確認できます。
レポートは明らかに 6 から強化されており、いくつかの非常に優れた機能を備えています。特に、特定の条件下で「いつ印刷するか」やオーバーラップ コントロールを実行する必要のない、複数のリンク テーブル レポート領域があります。これは、最終レポートに必要な複数の関連テーブルに最適です。
問題ごとに SQL SUM() グループの 1 つの更新。私はあなたが
NVL( SUM( what ), 0 ) を FinalColumn として選択します。条件を満たしたレコードがない合計に遭遇した場合、NVL() はその null 値を取得し、それを強制的にゼロにして、その後の NULL の問題を防ぎます... 同様に、 MIN()、MAX()、AVG() などに適用されます。
それらは私を睨みつける大きなもののほんの一部です...
今週、VFP 6 アプリの問題をいくつか処理しましたが、VFP 9 SP2 で問題を簡単に解決できるため、非常にイライラしていました。
注意すべきもう 1 つの点は、データが VFP 6 ODBC ドライバーによってアクセスされる場合です。データベース イベントのような VFP 7 から VFP 9 に実装された新しいデータベース機能のいずれか、または varchar のような新しいデータ型を使用すると、データは ODBC ドライバーが処理できない形式に変換されます。代わりに新しい VFP OLE DB ドライバーが使用され、一部のツールは OLE DB 機能を処理できません。
新しいレポート デザイナーの方がはるかに強力であることがわかりますが、レンダリングに使用される GDI+ では、オーバーフロー スターを取り除くために、レポートのフィールド サイズを微調整する必要があります。Alan が指摘しているように、SET REPORTBEHAVIOR を使用するとこれを回避できますが、実際にはレポート プレビュー機能を利用する必要があります。
あなたがやけどをするかもしれないもう1つのことは、AFIELDS()コマンドが配列にさらに多くの要素を作成することです。そのため、作成された配列内の追加の行を処理するために、いくつかのコードを微調整する必要がある場合があります。
問題が発生した場合は、ここに投稿してください。私たちがお手伝いします。
リック・シューマー
全体的に痛みは少ないと言えます。DRapp で述べたように、SQL-SELECT ステートメントを確認して、GROUP BY 句を修正することの長所と短所を比較検討するか、SET ENGINEBEHAVIOUR を使用する方が簡単かどうかを検討する必要があります。レポートは、SET REPORTBEHAVIOUR を使用して VFP6 のように機能させることができます。
また、VFP6 では行われない DBF を開くと、VFP9 ではいくつかのテーブル構造チェックが行われます。その結果、VFP9 で DBF ファイルを開くと、ヘッダー レコード数が実際のレコード数と等しくないため、エラー 2065 がスローされることがありますが、以前のバージョンでは問題なく動作していました。この動作は、SET TABLEVALIDATE コマンドで制御できます。
ここにはすでにたくさんの良い答えがあります。最近 vfp6 アプリを変換したので、特に vfp9 のエディターなどを使用することから得られる利点のために、プロセスは比較的簡単だったと思います.
指摘されていない項目が 1 つあります... すべてのレポートを確認し、[プリンタ環境を保存] レポート オプションがオフになっていることを確認してください。
ソースをVFP9にアップグレードする際にいくつかの問題が発生しました。しかし、それらのほとんどはかなりマイナーです。
最初に行う必要があるのは、VFP7、VFP8、およびVFP9の新着情報のドキュメントを確認することです。これは苦痛のように思えますが、プロジェクトをアップグレードするときの最初のストップになるはずです。VFP6以降のドキュメントは、MSDNにあります。
多くの新しいプロパティとメソッドがクラスに追加されました。これらのいずれかがカスタムプロパティ/メソッドと競合する場合、エラーが発生します。
また、VistaUACの要件とその対処方法を理解する必要があります。VFP8以下でコンパイルされたプログラムは、「互換」モードで実行されます。VFP9では、プログラムはVistaアプリケーションマニフェストでコンパイルされます。つまり、アプリケーションマニフェストのrequestedExecutionLevelはasInvokerに設定されます。VFP8以下では、これはマニフェストに含まれていません(または、マニフェストがまったく含まれていません)。したがって、互換モードです。
これは、Vistaでプログラムを実行すると、いくつかのことが失敗したり、エラーが発生したりすることを意味します。
アプリケーションマニフェストを更新するオプションがありますが、プログラムで管理者権限が絶対に必要な場合を除いて、必ずしもお勧めするわけではありません。
最後に、VFP9 SP2で修正された、Vistaの非互換性がいくつかあります(特にAeroを扱っているものもあります)。したがって、VFP9を使用する場合は、必ずServicePack2を使用してください。