PROPERTY:

shapeString

DESCRIPTION:

Indicates the Shape statement.

PROPERTY OF:

ADODataShape

DEFAULT VALUE:

Empty string

DESCRIPTION:

The shapeString property contains an Shape statement.

The shapeString property must be assigned before the ADODataShape object is activated.

You can use hierarchical rowsets as an alternative to JOIN and GROUP BY syntax when you need to access parent-child and summary data.

Hierarchical rowsets are used in many products: Xbase products use the SET RELATION command.

Hierarchies give you the ability to build one or several rowsets, define groupings, and specify aggregate calculations over child rowsets. 

Hierarchical rowsets differ from SQL JOIN and GROUP BY statements in that with a JOIN, both the parent table fields and child table fields are represented in the same rowset. 

With a hierarchical rowset, the rowset contains only fields from the parent table. In addition, the rowset contains an chapters that represents the related child data,

which you can assign to a second rowset variable and traverse.

When you are performing aggregate functions using GROUP BY and aggregate operators, only aggregate values appear in the rowset.

With hierarchical rowsets, the aggregate values are represented in the parent rowset and the detail rows are in the child rowset.

You can create three types of shapes, and each type has its own strengths and weaknesses.

You need to choose the mechanism that best fits the needs of your application and the environment 

you will be running your application in. 

The types of SHAPE are as follows:

- Relation Based 

- Parameter Based 

- Group Based 

The first two are similar in that they produce a hierarchy that would otherwise be represented by a SQL JOIN statement. 

They differ in that all the parent and child rows are read into a local cache before any processing continues 

in the relation-based hierarchy. This type of hierarchy has a high initial overhead when retrieving the rows, 

but the overhead is low after the initial retrieval.

Initially, parameter-based hierarchies only read the parent rows and fetch the child rows on demand. 

Though the initial overhead is reduced, you must issue a new child query for each parent record that is accessed, 

and you must maintain the connection to the datasource for as long as the rowset is open.

The group-based hierarchy is equivalent to producing an aggregate SQL statement joined to a detail SQL statement 

or performing aggregate functions on non-normalized data. 

You cannot update the summary fields and calculated fields because they might be derived from more than one row. 

Like relation-based hierarchies, all rows must be read up front.

Hierarchical rowsets are made available by the SHAPE clause.

A new clause, SHAPE, is provided to relate SELECT statements in a hierarchical fashion. 

The syntax is summarized below: 

   SHAPE {parent-command} [[AS] name]

   APPEND ({child-command} [[AS] name] RELATE parent-field TO child-field)

   [,({child2-command} ...)]

By default, the child recordsets in the parent recordset will be called Chapter1, Chapter2, etc., 

unless you use the optional [[AS] name] clause to name the child recordset.  

You can nest the SHAPE command. The {parent-command} and/or {child-command} can contain another SHAPE statement.  

The {parent-command} and {child-command} do not have to be SQL SELECT statements. 

They can use whatever syntax is supported by data provider.