Error 12882: Could not access element 'x' in class &

I'm surprised that you are wondering why you have a problem. From what I can see, you are creating at least 250,000 objects before the system crashes. That's 250,000 .r files loaded into memory and swap

Create one line object. Use that object to process each line. Do you really need an object per line ?

Julian

Well, there's a little detail I might have left out.

Because the file contains a few different kinds of lines with different values and information, I've created a class hierarchy with a base class 'Line' and a few (7) concrete line-classes that inherits this and implements the calculation-functionality based on the content of the line. So based on the type of line each line end up in an instance of one of the concrete line-classes.

I see your point in filling up the memory with instances, so just to make sure this would work if the garbage collector failed to do it's job i call DELETE-OBJECT v_line after each line before using the same variable to hold the class instance for the next line. I was hoping this would save me from memory-leaks, even if I do think the garbage collector would fix this for me.

Thanks!

-Thomas

ok, in that case I would still look at the objects in memory. Perhaps some aren't going away as expected, so you are still filling up ..

before and after every line do an object check:

DEF VAR hObject AS CLASS Progress.Lang.Object NO-UNDO.





DEF VAR lv_i AS INT NO-UNDO.



ASSIGN hObject = SESSION:FIRST-OBJECT.

    

DO WHILE VALID-OBJECT(hObject):

 ASSIGN lv_i = lv_i + 1.

 

 

 ASSIGN hObject = hObject:NEXT-SIBLING.

END.



MESSAGE lv_i "objects" VIEW-AS ALERT-BOX.

 

Obviously, the object count before each processed line should match the object count after each line (after you have deleted all your objects)

Thanks Julian, I'll try that.

Just out of curiosity: You say that 250.000 instances of a class results in 250.000 .r files loaded in to memory, is this the way the Progress OO runtime is implemented? I think that in an OO environment, the code should never be loaded in to memory, only the values (variables inside each instance) should be stored in memory (most of these values only contain references to other instances). The code, which is identical for each instance of a class, has nothing to do in memory but should be loaded and executed when needed (at most one representation of this code should ever exist in memory). If the runtime loads the complete r-code into memory (code and all) for each instance I make of a class, and therefore limiting the number of instances I could have in my program, I would say that object-orientation in Progress is a lie.

- Thomas

Thomas,

I've run into the error (12882) in cases where I'm dealing with a class that inherits from a .NET class. It's not clear from your post whether that's the case here. If it is, you may get some relief in 10.2B.

Either way, please report this to Tech Support.

Thanks,

-- peter

In my case there is no .NET classes involved. I inherit a ABL-class.

I'll report this and then try upgrading to SP 2, or wait for 10.2B. I've made a work-around for now.

Thanks!

- Thomas

I believe that, prior to 10.2B, you will actually get 250,000 loads of the code since, even if you are successfully deleting the object, then it isn't there any more.  In 10.2B this changes a bit and there is a pool of deleted objects ready for re-use.  But, I would expect that to have a performance impact only.

I would definitely take this to tech support for clarification.

As a work-around, though, you might consider altering the class so that it was possible to refresh it rather than delete it.  It isn't what I would prefer and it will have some complexity because of the inheritance tree, but it might give you a performance boost and it might avoid the problem.