Hi Bill,
I don't have much experience with trying to run code through the dbc, so I have little advice. You could advocate that he only use parameterized views. USE DetailsView--then he would have to specify the ?para and when he was done would have to say, DO PleaseUpdate.PRG. That way you could instantiate the needed classes and check the work before issuing TABLEUPDATE(). Once the user can work at the command window, I doubt if there's a sure way to validate. But as I admit, I use classes to validate and normally don't put anything into the DBC.

>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.