Jim,

That's a good example of when Set and Get methods can be better than Access and Assign. I see that there are times when Access and Assign aren't such a good idea, but I also think that there are times Access and Assign are effectively the equivalent. I don't think people should get hung up on the idea that you're allowing the user to directly set and get properties, since Access and Assign allow you to have control over what happens when a property is set or accesed.

>Josh,
>
>I don't necessarily say that accessing properties is a bad thing, it some situaitons it is the simplest interface you can build. However, let me use a better example to explain the problem.
>
>We build a customer object (business object) and use its properties to store the current records field values. This object has Company, Addr, City etc. properties.
>
>Second scenario, we build the same customer object except it has a GetFldValue and SetFldValue methods which accept the field name as a parameter.
>
>Initially the two designs are similar in complexity. The property design even seems a little cleaner (less code, more direct etc.).
>
>However, six months after release a field is added to the customer table in the database. The property design requires that the database by modified (to add the field), the business object be modified (to add the new porperty), and the UI be modified (to display the enw field).
>
>With the Get/Set methods you only need to modify two of the three tiers, because the business object can be coded to try to get whatever field value was requested without restriction. You add the field to the database, and modify the UI to display the field and that's it. No modifications required to the business object.