>I've considered binding controls to bizobj properties rather than to fields. But, while this sounds like great object-oriented design, it seems this would be an incredible headache and a real speed cow. With this design you would need to update the properties for every record pointer move. Maintainance would also be problematical. Adding or modifying fields in your tables would require you to go back and update your bizobj structure.
>

Michael,

Since the bizobj is inherently married to the data structures there is no way to use a bizobj that does require moidification whne the data structure changes.

What is so difficult about having a bizobj.GoNext method that handles the uopdating of all of the properties for you. In the Gonext you ahve the ability to have multiple different bizobj classes that handle navigation differently. To the interface, all there is is BizObj.GoNext and a refresh of the form. The bizobj decides how to go about getting the enxt record, it may issuing another SELECT to the backend or it may be a simple skip in a cursor, or it can be a call to a method of an ADO or RDO. The implementation is hidden from the interface.