>Hi, Kevin-
>
>>That sounds visable enough. If that was implemented, I could call the business object to switch records, which in turn will update the properties, and then display the records data.
>
>Yep. Exactly. From my article series in FoxTalk, I show an example of how a click on the Save button is processed thru the UI to the bizobj to the dataobj. Everything you want to do with a UI is mirrored in each layer. So, the UI (container with buttons, say) has a Save, the BizObj has a Save, and the dataobj has a Save. What's very cool about bind events in 8.0 is you can leverage this all to _easily_ update different fellows as necessary. (My next article which will appear...sometime, not sure when) shows this. So, for example, I have on the UI a container with the data objects and a container with the command buttons. Obviously on the UI front, when Save is pressed a bunch of things have to happen. The problem historically has been, how do you get the message from the Save button to the data layer and to the navigation buttons, so they can be refreshed, and to the other command buttons, so they can be refreshed. It's possible in <7.0 only by some fairly icky contortions. With
>BindEvents it's unbelievable simple. Just for an example:

BINDEVENT(THIS.objDataCmd,"Save",THIS.objPerson,"Save",2)

>If you are going to be deploying later this year, then I'd heartily encourage you to use the 8.0 beta so you can make use of this feature. It is such a fundamental architecture decision that it should be made early, IMO. You may of course already be using it, in which case I apologize for telling you something you already know.

Thankfully I am using VFP8 Beta, we will probably be buying the full version as soon as release, but thanks for highlighting this.

>BTW, Mike Helland is writing an indepth series on BindEvents for FoxTalk. I think the current issue has his 2nd article on the subject.
>
>>This would also deter the need for the knowledge of what the fields names are in the tables, as the properties would be self explanatory.
>
>Yeah, that's why I went with Set and Get. I tried to use SCATTER NAME to make a data object, it's a great command. However, when I extended the data objects to support ADO recordsets, it became untenable. A SCATTER NAME object is structurally different from an adorecordset, and so I found I was doing code gyrations just to make them isomorphic at the data object leve. I'm sure it was just me, but it felt awkward. Using pure objects feels better...get away from the actual data structure as soon as possible, is my motto. :)
>
>>Although, saying that, for some reason, I was thinking of passing recordsets of data around, and have the controls bound to them, then pass them back for saving/undoing to the business object.
>
>Yep. I tried that. Didn't like it. Mostly for performance. I wanted to maintain as much of the speed of the Fox data engine as I could _if_ the back was Fox.
>
>>It's a real rat's nest, IMO, I'm having second thoughts about going in this direction already.
>
>That's what I found, but I know others are quite comfortable with it.

Thanks for all your help, you've made alot of things clearer, especially with regards to looking at individual records. Getting a "list" of records can be achieved by requesting a recordset or XML, which is very straightforward, it was the individual record manipulation I was getting stuck on.

Thanks again
Kev