The access and assign methods seem to me to be VFP's answer to the Property LET and Property GET methods of VB. I have a VB example, but it could just as easily be VFP example (and better too!)

One of my colleagues build a set of database record classes. So, when you want the retrieve the first name of a person you would do:
Set ox = CreateObject("DatabaseServices.Employees")
ox.key = "Smith"

var_firstname = ox.firstname

In the above, firstname is a property of the ox object. But firstname is really a method returning a value. In the example above setting the var does a call to Property Get FirstName() && same as firstname_access

In this method, there is a check to see if the ado recordset object has been created. The recordset only gets created the first time a property is accessed. Also, does it need to be requeried? (an internal flag is set to yes whenever the key property is set!). If so the recordset is requeried, the flag reset, and then the recordset property firstname is returned.

If you next do
var_lastname = ox.lastname
The same functionality is performed, but the recordset exists, the flag says don't requery, so the recordset property is returned.

In the actual object, there are global (within the class) variables for each property and when the recordset is retrieved, these are all set with the current value, and the recordset is then closed).

If your data access is through a VFP COM Object acting as a middle tier, then this is an excellent approach. You can't access the cursor created in the middle tier directly, so your access to data is through properties of the object.

Your front end activity is merely accessing or assigning values to the objects properties. Internally, the object would do the retrieval, the updating of the data, the setting of flags etc. For instance, to add a new record, you do ox.Add() or even ox.Add = .t. This method signals the object that an add is in place. Next, you assign some property values and then release ox. In the destroy code, the object sees that it needs to save data to the database and does so automatically.



>Mike,
>
>>In that case, the bottom line is, for another developer using your classes or forms wants to change xProp, he sets it. If the value is totally off, you can give himw a property specific detailed message. Otherwise he would try it, find out the properties hidden, perhaps stumble accross the SetXProp method, than have to learn any syntax.
>
>Hmmm. I'm not sure if this would be a disadvantage. I really dislike the idea that a ASSIGN event could rollback a value without a error message or warning. This could make error tracking a real hell.
>
>What if this property was set at Development in stead of runtime ?? It won't work. If the assign statement would work in development time, I agree, it would help to hide implementation details of objects.
>
>
>Walter,