0

I have this code

n_userobject    inv_userobject[]

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

dw_1.rowcount() returns only 210 rows. Its so odd that in the range of 170 up, the application stop and crashes on inv_userobject[i] = create n_userobject. My question, is there any limit on array or userobject declaration using arrays? I already try destroying it after the loop so as to check if that will be a possible solution, but it is still crashing. Or how can i be able to somehow refresh the userobject? Or is there anyone out there encounter this?

Thanks for all your help.

Terry
  • 6,160
  • 17
  • 16
icing1018
  • 21
  • 2
  • 4
  • What version of PB are you using? What is the error you get when PB crashes? What is in n_userobject? – Hugh Brackett Jul 01 '11 at 18:33
  • Try sticking some Yield() statements, just a shot in the dark. Could be timing not sure if you are attempting to instantiate several nvo's at a time, but it looks that way since you're using an index so I thought the Yield() or a delay between iterations might help. Watch your memory with task manager while this is running see if it is killing memory like a night at the bar. – Rich Bianco Jul 30 '11 at 16:58

4 Answers4

2

First, your memory problem. You're definitely not running into an array limit. If I was to take a guess, one of the instance variables in n_userobject isn't being cleaned up properly (i.e. pointing to a class that isn't being destroyed when the parent class is destroyed) or pointing to a class that similarly doesn't clean itself up. If you've got PB Enterprise, I'd do a profiling trace with a smaller loop and see what is being garbage collected (there's a utility called CDMatch that really helps this process).

Secondly, let's face it, you're just doing this to avoid writing a reset method. Even if you get this functional, it will never be as efficient as writing your own reset method and reusing the same instance over again. Yes, it's another method you'll have to maintain whenever the instance variable list changes or the defaults change, but you'll easily gain that back in performance.

Good luck,

Terry.

Terry
  • 6,160
  • 17
  • 16
1

I'm assuming the crash you're facing is at the PBVM level, and not a regular PB exception (which you can catch in your code). If I'm wrong, please add the exception details.

A loop of 170-210 iterations really isn't a large one. However, crashes within loops are usually the result of resource exhaustion. What we usually do in long loops is call GarbageCollect() occasionally. How often should it be called depends on what your code does - using it frequently could allow the use of less memory, but it will slow down the run. Read this for more.

If this doesn't help, make sure the error does not come from some non-PB code (imported DLL or so). You can check the stack trace during the crash to see the exception's origin.

Lastly, if you're supported by Sybase (or a local representative), you can send them a crash dump. They can analyze it, and see if it's a bug in PB, and if so, let you know when it was (or will be) fixed.

Eran
  • 21,632
  • 6
  • 56
  • 89
0

What I would normally do with a DataWindow is to create an object that processes the data in a row and call it for each row.

Hugh Brackett
  • 2,706
  • 14
  • 21
0

the only suggestion i have for this is to remove the rowcount from the for (For i = 1 to dw_1.Rowcount()) this will cause the code to recount the rows every time it uses one. get the count into a variable and then use the variable. it should run a bit better and be far more easy to debug.

TomG
  • 51
  • 1
  • 4