Hi Ken,

Data objects are a wonderful way in which to "standardize" data access. By creating an object whose properties, which have the same names as the field names within the table, contain the field values for the record the object represents.

Once you have an object representing your data, you can do many things with it. You can have a special class whose entire purpose is to talk with the back-end and create object representations for data. You can also combine the data object with something like a record object, which contains identifying information about the record and some methods that can be called so that when you want to save the record, you could essentially say something like oRecord.Save(). This way, the record knows how to save itself and all the work is done simply by calling that method.

Furthermore, once data is represented by an object, many of the data session problems disappear. You may not be able to pass a table or cursor across datasessions, but you certainly can pass objects across data sessions.

Object representations for data can be further exploited since you can pass them across OLE channels so that a VB program can receive and work with the object and then pass it back.

Plus, in using objects to represent data, you can support "incompatible" back-ends by simply providing instructions on how the object is to be created. You can add additional "fields" to the object as properties that may reside in other tables. For instance, let's say you have a Customer and an Invoice table. When you're working with an invoice, you may wish, when working with the Invoice data object, to access certain fields from the Customer table. You can accomplish by simply adding a property to the data object once it's been created to hold an object reference to the "parent" table.

>I have heard rumors of people placing data in objects but my feeble mind cannot grasp why? What are the advantages to creating objects for data?