Hi Paul

>I have a select statement that calls a method to return a value:
>
>Following is a stripped down version to get the gist.
>

>   select vin_ref, thisform.yGetAging()as vin_aging
>      from scvndino
>
>*yGetAging Method*
>with thisform
>   do case	
>      case vin_duedate  >= .ydDate
>         return 'Current'
>      case between(vin_duedate,.ydDate-10,.ydDate - 1)
>	 return '1 - 10'
>      case between(vin_duedate,.ydDate-20,.ydDate - 11)
>	 return '11 - 20'
>      case between(vin_duedate,.ydDate-30,.ydDate - 21)
>	 return '21 - 30'
>      case between(vin_duedate,.ydDate-60,.ydDate - 31)
>	 return '31 - 60'
>      case between(vin_duedate,.ydDate-90,.ydDate - 61)
>	 return '61 - 90'
>      case between(vin_duedate,.ydDate-120,.ydDate - 91)
>	 return '91- 120'
>      otherwise
>	 return '121+'
>   endcase
>endwith
>
>

>
>Prior to VFP 9 this worked fine. I am finding now that the record pointer in the scvndino table is not on the correct record anymore in the method. If the select statement is going through a hundred records this method returns the results for the first record in the table all 100 times.

No offence, but I keep finding myself saying this: Just because something works doesn't mean it's right.

>
>Sending vin_duedate as a parameter to the method and replacing "vin_duedate" with this parameter DOES work. My concern is that I have code like this all over the place. Is there something else I'm missing?

In OOP there's this idea of encapsulation, where data and programming is contained. Without passing the parameter into the method, there is an assumption that things are correct, but encapsulation is lower because the value is not contained inside the method, but is residing outside the method.

Passing it in as a parameter is a good way to ensure the right value is used. It allows you to test the method without having a data file present / open. By the way, calling a method is quite a bit slower than calling a PRG/UDF.