I like the session class, which has to be created in a prg. The private datasession option then allows you to isolate your tables from the rest of your app in a secure way. We've found since switching to this kind oa scheme that our errors and data reliability has improved dramatically.

Our session "base class" is a .prg file which simply contains

define class session_q as session
	cErrMsg= ""
	datasession= 2
	ndatasessionid= 0
	ok= .f.

	**************************
	procedure init
	**************************
	set talk window
	set date dmy
	set multilocks on
	set deleted on
	set safety off
	set confirm on
	set hours to 24
	set reprocess to auto
	* to make it easy for subclasses to restore datasession
	this.nDataSessionId= this.DataSessionId
	endproc
enddefine	&& class session_q

You then subclass this for specific modules, open your tables in the init method and away you go.
I guess it's essentially a business object then.

We use a convention that prg files which start with ds_ are session classes based on above
eg. here's a VERY VERY cut down version of a phone number class, ds_phone.prg, through which every module in all our apps access and manage phone numbers. Just to give you ideas...

define class PhoneClass  as session_q of qsession.prg
	cPhone= ""
	oPhone= .null.
	connum= 0
	custnum= 0
	dimension a_type[11,2]
	nLenPh= 0

	procedure init
	*******************************
	dodefault()

	* data required...
	use Names in 0
	use Cons in 0
	use Phone in 0
	* so we can move the pointer around independently of Phone itself
	use Phone in 0 again order RevPhone alias PhoneX

	this.nLenPh= len(Phone.Phone)
	cPhone= space(len(Phone.Phone))
	endproc

	procedure addRec(oRec)
	*******************************
	insert into Phone from name oRec
	
	procedure delete_custnum
	*******************************
	lparameters nCustNum
	do while seek(m.nCustNum, 'Phone', 'CustNum')
		delete in Phone
	enddo
	endproc
enddefine

>I have a function that is called that does ONE of two possible things based on how it is called:
>
>1. Creates a table with required basic 'core' records.
>2. Adds additional 'detail' records based on the values passed.
>
>I pass the below values to the function:
>
>

>*:          Usage: =SysInfo(tcgroup, tcsubgroup, tcitem, tcsubitem, tcvalue, tlcreate)
>*:     Parameters: tcgroup      c65   - group value i.e. Agency Name/Site Name
>*:                 tcsubgroup   c65   - subgroup value i.e. Workstation Name
>*:                 tcitem       c65   - item value i.e. User Settings
>*:                 tcsubitem    c65   - subitem value i.e. Deleted
>*:                 tcvalue      M     - detail value i.e. ON or OFF, etc.
>*:                 tlcreate     L     - logical create groups/subgroups/etc or not
>

>
>If tlcreate is passed, then the table is created with certain basic records which allow it to be viewable easily in a treeview. The record is populated based on the values passed in the other parameters.
>
>If tlcreate is not passed (or passed as false), then the values are being passed which then creates a detail record or overwrites one if the settings have changed for that subitem.
>
>The table stores system settings such as set deleted, set near, login id, workstation name, hard disk space, memory, etc and is broken down by agency name and workstation.
>
>It works fine as is, but:
>
>I want to change this program to a class. Which type of class is best to use for one that will never be visual except when creating the properties during development?
>
>My idea is to set the value of properties on the class with the values passed to the function now, and then call a method of the class to process those values.
>
>
>THANKS,
>Tracy