If you want to see what the code looks like for the super(), you need to find out what the current class is extending and then go look at the method with the same name in that class :) Easy ya? Not so when working with tables in axapta :) I believe their base class is hidden from us, and thus we are unable to peek into it's workings like we would a regular class. However, in a case like yours, the error message was valid. So even if you had been able to drill into the inner workings, you would not have found anything interesting. Merely, a check that the version of the row in the db was the same as the version on the "this" object. It failed the check, then threw the error. The real question is why was your object failing the check - and that could not be answered by looking at the code that threw the error. It can only be understood by understanding the larger picture of what the code is doing. It is more of an architectural question...
--- On Thu, 10/9/08, Jacques Oelofse <[EMAIL PROTECTED]> wrote: From: Jacques Oelofse <[EMAIL PROTECTED]> Subject: Re: [development-axapta] Re:CustTable Super() To: development-axapta@yahoogroups.com Date: Thursday, October 9, 2008, 11:17 PM Tx for the help everyone! We found the problem eventually it was something completely unrelated although was still wondering if there was a way to debug and be able to track exactly where the error is coming from when it happens in the super() method. Cheers, Jacques Tony Zeigler wrote: > > He said it occurs in the super() - which would make sense if he had > confused the system about a prior change. > > For instance, if his code elsewhere creates two copies of the > CustTable row, and modifies both before saving, then his second copy > will blow up with that error when he calls super. > > For instance something along this line should do the job: > CustTable custtablea; > CustTable custtableb; > ; > select custtablea where recid = 1; > select custtableb where recid = 1; > custtablea.name = "Changed"; > custtableb.name = "ChangedAgain" ; > custtablea.save( ); > custtableb.save( ); > > In this example I believe custtableb will blow up with his error when > it calls the super()... > > Since the actual root cause of the error is outside the super() it can > be a pain in the arse to track these down.... > > --- On Wed, 10/8/08, Brandon Boman <brandon.boman@ wellpointsystems .com > <mailto:brandon. boman%40wellpoin tsystems. com>> wrote: > > From: Brandon Boman <brandon.boman@ wellpointsystems .com > <mailto:brandon. boman%40wellpoin tsystems. com>> > Subject: [development- axapta] Re:CustTable Super() > To: development- [EMAIL PROTECTED] ps.com > <mailto:development -axapta%40yahoog roups.com> > Date: Wednesday, October 8, 2008, 10:44 PM > > Hi there > > In which method does the error occur? > > Brandon Boman > > System Analyst / Developer > > iSoft Technologies (Pty) Ltd > > by WellPoint Systems Inc. > > 49 Sovereign Drive, Route 21 Corporate Park > > Irene x30, South Africa > > Phone +27 (12) 345-4750 > > Fax +27 (12) 345-4252 > > Email: brandon.boman@ wellpointsystems .com > > www.wellpointsystem s.com <blocked::http://www.wellpoin tsystems. com/> > > [Non-text portions of this message have been removed] > > [Non-text portions of this message have been removed] > > [Non-text portions of this message have been removed] [Non-text portions of this message have been removed]
