Data Object

Data Objects describe the SQL Server database tables used for data storage and retrieval for an Object. An Object must have at least one Data Object record and can theoretically have an unlimited number of object data records. Think of data objects as the tables that are associated with the Object.

In most cases, and Object will have a primary data object, and may have one or more secondary objects. The primary data object's prefix will be the same prefix as the Object.

 Data Object

Uses

Data Objects determine which fields can appear on Forms of an Object and therefore determine what data is inserted, updated, deleted and selected.

Controls

  • Object: The parent Object of the Object Data.
  • Description: The description of the Object Data.
  • Parent/Foreign Key: if the table name of this Object Data is a parent table to your Object’s primary table, then you will enter the foreign key column of the main table that stores the value that joins back to the main table.

For example, the Address Change Log table co_address_change_log contains records that are child records of an Address co_address. The column co_address_change_log.acl_adr_key is the Foreign Key to the column co_address.adr_key.

On the Address Change Log Object, we have an Object Data for Address. The Parent/Foreign Key in this instance is acl_adr_key because this is how the core table co_address_change_log for this object joins to its parent row in co_address. This Object Data is illustrated here:

Object Data for Address Change Log


The data types of the parent and foreign key columns must be a GUID. Although there are examples of foreign keys that store strings in the NetForum database, data objects based upon this will not be able to select the "foreign" record when a record is loaded.

  • data object prefix/qualifier: This will almost always store the three-character prefix of the columns in the table name. In some instances, one Object may have two or more Object Data records pointing to the same table name. In this case, you must supply different data object prefix-qualifiers for each Object Data.

Here is an example of one Object having more than two Data Object records pointing to the same table. The CO_Customer_X_Customer object relates two customers together. This Object wishes to interface with the co_customer table record belonging to the Individual and to the Organization. Therefore, we create two Object Data records for this purpose as shown below:

Object Data advanced


Note how the first Object Data to co_customer uses the data object prefix/qualifier of cs1 while the second instance uses cs2. When accessing the data items in code with GetValue or SetValue the alternate prefix with a double underscore is prepended to the column name. Example: to reference the cst_key of the second instance of the customer object use cs2__cst_key.

  • Table Name: The name of the table being described by the Object Data.
  • Extender table name: The name of the extender table (if any) that is associated with the table name.
  • prefix: the 3-character column prefix of the table name.
  • extender table prefix: The 3-character column prefix of the extender table name (if any). In practice, the extender table prefix (if there is an extender table) will always be the same as the prefix.
  • key field: The primary column of the table name.
  • extender key field: The primary column in the extender table (if any) that joins back to the key field.
  • delete flag field: The delete flag column of the table name.
  • load order: This value sets the order in which the Object Data records are loaded into the Object. If one Object Data depends on another, then the dependent Object Data must have a Load Order higher than the Object Data it depends on.
  • save order: Similar to load order, this value sets the order in which data of Object Data is saved. This is relevant only if the do not save data? checkbox is unchecked.
  • do not save data? Check this checkbox for read-only Object Data records that can be viewed by the Object, but should not be saved. Typically, if the Object Data is for a parent record to the core Object Data of the Object, then this checkbox should be checked. This will ensure that a user editing a child record on a Form of this Object cannot save any information about the parent record. In some advanced cases, however, a parent facade class will have data object for one-to-many child tables that will save data, for example the Publication facade class can save data for Prices and Price Attributes.
  • one-to-many?: check this checkbox if the Object Data is for a table that is a child table of the core Object Data of the Object. For example, the Mailing List object has an Object Data for Mailing List Details (mk_mailing_list_detail), and on this Object Data the one-to-many checkbox is checked. Another example is the Publication facade class that has child data objects for Price and Price Attribute. If you check one-to-many, then this will effectively make the data object implement the "do not select" setting, whether you have checked "do not select" or not.
  • Do Not Select - rarely used. Note: if you have a data object that is one-to-many, then the setting for this checkbox is irrelevant; netFORUM will implicitly not select data from data objects that have the one-to-many property. netFORUM cannot "select" data from one-to-many data objects because the "select" method is geared toward selecting a single record, not a record along with collection(s) of child records.

FAQ

Q. Why do some objects not have any Data Objects?

A. Static Facade Objects do not use Data Objects from Toolkit metadata. Instead, their data objects are initialized in C# programming code. You will know that an Object is a static object if the assembly is something other than Data.

Q. How, then, do I know what the Data Objects are in a Static Facade Object?

A. From the Object page, run the List Object Controls link and you will see the data objects. You can get this information as well from the GetFacadeXMLSchema xWeb web method.

See Also