2011-07-01 166 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

我通常會用DataWindow做的事情是創建一個對象,該對象處理一行中的數據併爲每行調用它。

1

我假設你面臨的崩潰是在PBVM級別,而不是一個普通的PB異常(你可以在你的代碼中捕獲到)。如果我錯了,請添加例外詳細信息。

170-210次迭代的循環確實不是一個大循環。但是,循環內的崩潰通常是資源耗盡的結果。我們通常在長循環中做的事情是偶爾撥打GarbageCollect()。應該多久調用一次,取決於代碼的功能 - 經常使用它可以允許使用較少的內存,但會降低運行速度。 Read this瞭解更多。

如果這沒有幫助,請確保錯誤不是來自某些非PB代碼(導入的DLL等)。您可以在崩潰期間檢查堆棧跟蹤以查看異常的來源。

最後,如果您受Sybase(或本地代表)支持,則可以向它們發送故障轉儲。他們可以分析它,看看它是否是PB中的錯誤,如果是,請告訴你它什麼時候(或將要)修復。

+0

謝謝,我會嘗試一個。 – icing1018

2

首先,你的記憶問題。你絕對不會遇到數組限制。如果我要猜測,n_userobject中的一個實例變量沒有被正確清理(即指向一個在父類被銷燬時未被銷燬的類),或者指向類似的類, t清理自己。如果你有PB Enterprise,我會用一個較小的循環做一個分析跟蹤,看看什麼是垃圾收集(有一個名爲CDMatch的實用程序確實有助於這個過程)。其次,讓我們面對它,你只是這樣做,以避免寫一個重置方法。即使你得到這個功能,它永遠不會像編寫你自己的重置方法和重新使用同一個實例一樣高效。是的,這是另一種方法,只要實例變量列表發生更改或默認值發生變化,您就必須維護這些方法,但您很容易在性能上獲得回報。

祝你好運,

特里。

0

我唯一的建議是從for(從i = 1到dw_1.Rowcount())中刪除rowcount,這將導致代碼在每次使用時重新計算行。將count存入一個變量,然後使用該變量。它應該運行得更好,並且更容易調試。