2011-07-01 16 views
0

に私はこのコードに配列は、PowerBuilder

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でクラッシュします。 私の質問は、配列を使用して配列またはuserobject宣言に任意の制限はありますか? 私はすでにループの後にそれを破壊して、それが可能な解決策になるかどうかをチェックしようとしていますが、まだクラッシュしています。 または、何とか私は何かをすることができますrefresh userobject? これに出くわした人は誰ですか?

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

+0

どのPBのバージョンをお使いですか? PBがクラッシュしたときに発生するエラーは何ですか? n_userobjectには何がありますか? –

+0

いくつかのYield()ステートメントを暗闇の中で執着してみてください。一度に複数のnvoをインスタンス化しようとしているのかどうか確信が持てないかもしれませんが、インデックスを使用しているのでそのように見えるので、Yield()や反復間の遅延が助けになると思います。これが実行されている間、バーで夜のようにメモリを殺しているかどうかを確認しながら、タスクマネージャであなたの記憶を見てください。 –

答えて

0

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

1

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

170-210回の繰り返しのループは実際に大きなものではありません。しかし、通常、ループ内のクラッシュはリソースの枯渇の結果です。長いループで通常行うことは時折GarbageCollect()と呼ばれます。呼び出す頻度はコードの内容によって異なります。頻繁に使用するとメモリの使用量は少なくなりますが、実行速度が遅くなります。詳細についてはRead thisをご覧ください。

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

最後に、Sybase(または現地代理店)のサポートを受けている場合は、クラッシュダンプを送信できます。彼らはそれを分析して、それがPBのバグかどうかを調べることができます。そうであれば、それが修正された(または修正される)時期をお知らせします。

+0

ありがとう、私は1つを試してみましょう。 – icing1018

2

まず、メモリの問題です。あなたは間違いなくアレイ制限に遭遇していません。私が推測すると、n_userobjectのインスタンス変数の1つが適切にクリーンアップされていない(つまり、親クラスが破棄されても破壊されていないクラスを指す)か、同様に、自分自身をきれいにする。 PBエンタープライズを持っているなら、私は小さなループでプロファイリングトレースを行い、何がガベージコレクションされているのかを見てみましょう。CDMatchというユーティリティがあります。

第2に、リセットメソッドの作成を避けるためにこれを行うだけです。この機能を有効にしても、独自のリセットメソッドを作成し、同じインスタンスを再利用するほど効率的ではありません。はい、インスタンス変数リストが変更されたとき、またはデフォルトが変更されたときには、保守する必要があるもう1つの方法ですが、簡単にパフォーマンスを向上させることができます。

幸運、

テリー。

0

これは、for(i = 1〜dw_1.Rowcount()に対して)からrowcountを削除することだけです。これにより、コードを使用するたびに行が再計算されます。カウントを変数に代入してから変数を使用します。それは少し良く動作し、デバッグするのがはるかに簡単になるはずです。

関連する問題