>AFAIK, VMP does not provide for business objects as a part of the framework.

VMP does not provide for business objects (yet) but it does provide a function (x3BTable) to find the table that underlies a ControlSource.

>I think that this would get you closer. You then have the ability to use separate 'rules' tables for each object. But then again, if you have a separate object for each entity, what's the matter with a validation method in each? Unless you need to allow the user to adjust validation code themselves, I don't see much advantage to storing code in tables.

Erik, please comment on the following BizObj class hierarchy:

1. bizContainer class. Instantiated as global variable. Provides single point of call.
1.1 Properties: Those needed to keep track of AddObjected bizObjects.
1.2 Methods:
AddBizObject: AddObjects biz object to itself;
ValidateField: Passes call to appropriate BizObj
ValidateRecord: idem
1.3 Example of use: Permits generic calls in the framework, such as oBiz.ValidateField(This) within the valid of interface controls.

2. bizBase class. Base class for BizObjs.
2.1 Properties: RuleTable, DataTable. Empty here, defined in subclasses.
2.2 Methods:
ValidateField. Generic code that looks up code in RuleTable and executes it.
ValidateRecord. Similar generic code for RecordValidation.

3. bizXXXX. BizObj class for a specific entity.
3.1 Properties: RuleTable and DataTable defined here.
3.2 Methods: Besides those inherited, contains “domain specific methods that represent actions that can be performed on the represented entity”.
3.3 Example of use: oBiz.bizEmployee.AccruedVacation().
3.4 If this class is defined in code, it eases the maintenance of the “domain specific methods”.

Besides trying to create a sound middle tier citizen, I am trying to do it in a way that is practical for my programming style (it leans towards code).

Thanks for your help.

Alex