Hi Charlie,
I'm not sure that either option would work for me. If I'm missing something, I would appreciate you pointing it out.

I have a client, that knows how to use VFP at a basic level. He will sometimes just "Use Details", "Browse", and change a field. I need to have SOME business rules built into the Validation Rules, and they need to operate from the command window.

An example:
He has a Details.dbf and a Totals.dbf where Totals.TD = Sum(Details.TD) and Details.TD = Details.ND + Details.RD + Details.WD. He will frequently just "Use Details", "Browse" and change WD (and he wants to see the changes relected on the screen). So the Field Validation for Details.WD has to "Replace TD with ND + RD + WD" and the Field Validation for Details.TD has to "Replace Totals.TD with Sum(Details.TD)" (it's not really that simple, but you get the idea). He will sometimes, but usually not, do this while a form is active with a private DS, which means that the Validation Object needs to know which DS the tables are in.
So the Validation Object has to be able to work with or without a DE open, and I can't just pass the data to validate, because it also needs to "Replace ...." in the same table or another table.

I've tried putting something into the dbc_AfterOpenTable(cTableName) that would handle this, but the app uses an awful lot of "Select ...." and it slows the app down to an absolute crawl because the "Select ..." opens and closes all the tables each time.



>Hi Bill,
>We use the same sort of structure as you are describing--but each cursor object has its own validation object.
>As I see it, you have two options.
>1. Create validation objects in the same DS as the cursors.
>2. Pass the data you wish to validate to the Validation object.
>Taking 1. first.
>We have a DE class that contains all the cursor objects that we are concerned with for a specific form or task. Each cursor object has its own Validation and Rules object. We have a couple of subclasses of validation objects--some store messages in an array, some in with the data. The rules deal with EnableDelete, EnableAdd and such. If you can't delete for example, the WhyICantDelete property shows the reason.
>The validation object lives in the same DS as the cursor, a view in this case, so it has access to the fields. Here's part of what happens--this is from memory, so I might leave quite a bit out.
>

>In the Form's Validate()
>Message = ''
>Severity = 0
>IF ThisForm.oData.Validate(@Message, @Severity)
>   * Everything checked out.
>   Action = "Save"
>ELSE
>   Action = ThisForm.GetUserInput(m.Message, m.Severity)
>ENDIF
>RETURN ThisForm.DataAction(m.Action)
>* Return .T. to indicate OK to go on. .F. means stay here.
>
>In the DE's Validate(Message, Severity)
>FOR EACH oCursor IN This.aCursors
>   oCursor.Validate(@Message, @Severity)
>ENDFOR
>
>In each cursor class's Validate(Message, Severity)
>ChangedRecNo = GETNEXTMODIFIED(0,.Alias)
>DO WHILE NOT m.ChangedRecNo = 0
>IF This.oValidate(@Message, @Severity)
>
>* BaseClass does this from the list of fieldnames. This enables the form
>* to call these same methods as needed.
>IF PEMSTATUS(This, "v" + m.FieldName,5)
>   * Now validate this field.
>   RetVal = EVALUATE( "This.v" + m.FieldName + "()" )
>   * Valid must set the Message and Severity properties.
>   IF NOT m.RetVal
>      Message = m.Message + This.Message + CRLF
>      Severity = MAX(m.Severity, This.Severity)
>   ENDIF
>ENDIF	
>RETURN m.RetVal
>
>* In the SubClass I write the methods needed to validate.
>PROCEDURE vFirstName()
>LOCAL RetVal
>IF EMPTY(Customer.FirstName)
>   This.Message = "Fill this in."
>ELSE
>   RetVal = .T.
>ENDIF
>RETURN m.RetVal
>
>or
>
>PROCEDURE vSSN
>LOCAL RetVal, Name
>Name = ''
>IF This.oParent.Check4Dupes(Customer.SSN, @Name)
>   * oParent is the cursor object that created this Validation object.
>   * Can't use addobject, so we use this property to refer to our creator.
>   RetVal = .T.
>ELSE
>   This.Message = "SSN-" + Customer.SSN + " has already need used by " + m.Name + "."
>   This.Severity = 4   && Warning.
>ENDIF
>
>Taking the 2. approach.
>I haven't done this, but here you could do methods like this.
>SCATTER NAME oRecord MEMO
>IF This.Validate(oRecord, @Message, @Severity)
>* Here the Validation object is passed the data to validate.
>* or
>IF This.Validate(oCursor, oRecord, @Message, @Severity)
>* Your validation object now can check for consistency of the data, and if
>* it needs access to the DS, it can call a method back in the cursor object.
>IF oCursor.Look4Dupes(m.ID, Message)
>

>
>>I'd be interested in your opinion on how to do this in an OOP sense.
>>
>>I'm creating a Record/Field Validation Class. One sub-class for each table. Each field and trigger will have a method of it's own. The idea is that the parent-class has code that is used for EVERY table and then an individual sub-class for each table.
>>
>>The problem is having a single object doing validation for several different DataSessions. I figured that I would Create the object in DS 1, and pass the correct DS to the object. It worked fine for a while, but then stopped. When the code that is in the parent-class (the parent-class code would set the DS) called the individual method in the sub-class (in the same object), the DS went back to 1.
>>
>>It's starting to look like I'll have to create a different object for each table in each DataSession. I'll also have to figure out how to have the DataSession close the objects that are created in it, so the DS can be released. I was hoping to create each object once, then use it every time I opened the table it was created for.
>>
>>Any opinion is welcome.