Mark,

>So I guess if I just pop my "base" subclass of Session in my common procedure file PROC_VFP.PRG this might be a reasonable home for it.

Probably, if all the projects you build (including perhaps future middle-tier distributed COM servers) will also use that same common procedure file. You could, of course, keep it in a separate prg for ease of editing when first developing and testing the class, then move it to your proc_vfp.prg when it's mostly complete.

You just have to be sure that whatever PRG it's in has been SET PROCEDURE TO'd (how's that for slaughter of the language?)

>My various sub classes of my base could go into either a separate prg which just contains class definitions or I could just put them in my application specfic procedure file.

Or, you could have them all in individual prg's if you prefer and use

oCust = NEWOBJECT("boCustomer", "boCustomer.prg")

instead of CREATEOBJECT with SET PROCEDURE TO (as long as the prg with your base session class is in the SET PROCEDURE list).

This might be a good idea if you had multiple projects for multiple parts of a big system, which all used a few of the business objects with some overlap, although some have said that NEWOBJECT is much slower than CREATEOBJECT. I guess I should check that out, since I've used NEWOBJECT in a similar situation.

>Thanks again for such a great answer:)

Thanks. I'm sure others here have differing opinions, however, so maybe you will also hear from some of them to get a balanced view.