0

私はこのコードを持っています

n_userobject    inv_userobject[]

For i = 1 to dw_1.Rowcount()
inv_userobject[i] = create n_userobject
 .
 .
 .
NEXT

dw_1.rowcount()210 行のみを返します。170 以上の範囲で、アプリケーションが停止してクラッシュするのは非常に奇妙ですinv_userobject[i] = create n_userobject。私の質問は、配列または配列を使用したユーザー オブジェクトの宣言に制限はありますか? それが可能な解決策になるかどうかを確認するために、ループの後にすでに破棄しようとしていますが、まだクラッシュしています。または、どうすればユーザーオブジェクトをどうにかrefreshすることができますか? または、これに遭遇した人はいますか？

ご助力いただきありがとうございます。

4

4 に答える 4

2

まず、あなたの記憶の問題。あなたは間違いなく配列の制限に達していません。推測すると、n_userobject のインスタンス変数の 1 つが適切にクリーンアップされていない (つまり、親クラスが破棄されたときに破棄されていないクラスを指している) か、同様にクリーンアップされていないクラスを指している」それ自体をクリーンアップします。PB Enterprise をお持ちの場合は、より小さなループでプロファイリング トレースを実行し、何がガベージ コレクションされているかを確認します (このプロセスを実際に支援するCDMatchというユーティリティがあります)。

第 2 に、reset メソッドの記述を避けるためにこれを行っているだけです。これが機能するようになったとしても、独自のリセット メソッドを記述して同じインスタンスを再利用するほど効率的ではありません。はい、インスタンス変数リストが変更されたり、デフォルトが変更されたりするたびに維持する必要がある別の方法ですが、パフォーマンスを簡単に取り戻すことができます。

幸運を、

テリー。

于 2011-07-04T15:12:31.360 に答える
1

あなたが直面しているクラッシュは PBVM レベルであり、通常の PB 例外 (コードでキャッチできます) ではないと想定しています。私が間違っている場合は、例外の詳細を追加してください。

170 ～ 210 回の反復のループは、実際には大きなループではありません。ただし、ループ内のクラッシュは通常、リソースの枯渇の結果です。通常、長いループで行うことは、たまにGarbageCollect()を呼び出すことです。どのくらいの頻度で呼び出す必要があるかは、コードの動作によって異なります。頻繁に使用するとメモリの使用量が少なくなりますが、実行が遅くなります。詳細については、これをお読みください。

これで問題が解決しない場合は、PB 以外のコード (インポートされた DLL など) からエラーが発生していないことを確認してください。クラッシュ中にスタック トレースをチェックして、例外の発生源を確認できます。

最後に、Sybase (または地域の担当者) のサポートを受けている場合は、クラッシュ ダンプを送信できます。彼らはそれを分析し、それが PB のバグかどうかを確認し、もしそうなら、いつ修正されたか (または修正される予定か) を知らせてくれます。

于 2011-07-03T14:00:46.190 に答える
0

これについて私が持っている唯一の提案は、for（For i = 1 to dw_1.Rowcount（））から行数を削除することです。これにより、コードは行を使用するたびに行を再カウントします。カウントを変数に入れてから、その変数を使用します。実行が少し良くなり、デバッグがはるかに簡単になるはずです。

于 2011-11-16T16:57:26.193 に答える
0

通常、データウィンドウで行うことは、行内のデータを処理するオブジェクトを作成し、それを行ごとに呼び出すことです。

于 2011-07-01T18:36:33.830 に答える