Hi BOb,

Your suggestion of the abstract factory using aclasses.dbf first, then using classes.dbf is exactly what I was looking for.

The current implimentation of the abstract factory actually seems less OO in some respects. If an aclasses.dbf file was thrown into the mix it actually acts like a subclass of classes.dbf.

Actually, I don't see why the abstract factory has to be data driven with classes.dbf. The information provided in classes.dbf could be accomplished in a class with properties. Then I could subclass it for an application. I know adding properties to a isn't as easy as adding records to classes.dbf but what do I get in the end if I have to remember to keep my own application specific classes.dbf file and update it every time there is a new release of the framework? (I'll get off the soap box now!)

George