>Hi Evan,
>
>I was thinking about the .validate / .save question you asked last night at the chat. I don't think you would want to do what you mentioned. It would result in round-tripping data to the server.
>
>I've haven't done this but I think this is how it works. Perhaps someone with more experience can jump in and help out. :)
>
>Example:
>
>The physical representation would be:
>

ClientMachine-----AppServer------DBServer
>      |               |              |
>   Form for        Customer       Customer
>   Data Entry      BisObject        Data

>
>A component resides on AppServer named Customer
>The Customer component has 3 methods
>
>.Validate(ADOcursor)
>Parameter is a cursor with all the customer data,
>it returns a boolean specifing if the data is valid (.T.) or invalid (.F.)
>
>.Save(ADOcursor)
>Parameter is a cursor with all the customer data.
>
>.GetBrokenRules(ADOcursor)
>Parameter is a cursor with all the customer data,
>it returns an ADO cursor that contians 1 row for each broken rule.

This won't work. It isn't stateless. A better way is to have the UI send the data to a Save() method. Save() calls Validate(). Validate() returns a text string that contains the messages to be displayed for all data that fails validation. If empty, all data is valid and Save() calls the appropriate Data objects to save the data and then returns. If data fails validation, the text string is returned from Save() to the UI for display.

Remember that one of the rules of this thing is that you need to be stateless. You can't set properties and then retrieve them from another method call. Everything has to be handled in parameters and RETURN values.