An object that joins two datasets based on common data values.
RelQueryTable is a non-creatable object. References to non-creatable objects must be obtained through other objects.
Product Availability
Supported Platforms
Interfaces
| Interfaces | Description |
|---|---|
| IClass | Provides access to members that return information about and manage the class. |
| IConnectionPointContainer | Supports connection points for connectable objects. |
| IDataset | Provides access to members that supply dataset information. |
| IFeatureClass | Provides access to members that control the behavior and properties of a feature class. |
| IObjectClass | Provides access to members that return information about an object class. |
| IRelQueryTable | Provides access to members that define the Tables and the RelationshipClass used in a join. |
| IRelQueryTableInfo | Provides access to members that provide information about joins. |
| IRelQueryTableManage | Provides access to members that manage the query tables. |
| IRelQueryTableSettings | Provides access to members that RelQueryTable behavior. |
| ITable | Provides access to members that return information about and manage tables. |
| ITableCapabilities | Provides access to members that return information about and manage tables. |
| IVirtualTable | Indicator interface that identifies temporary memory tables. |
Event Interfaces
| Interfaces | Description |
|---|---|
| IObjectClassEvents (default) | Provides access to events that occur with an object class. |
Remarks
A RelQueryTable is a class that represents a joined pair of tables or feature classes.
A RelationshipClass is used when creating a RelQueryTable to specify the tables involved and the fields on which the join is based. The RelationshipClass can be stored in a geodatabase or created in memory. MemoryRelationshipClasses can include tables that belong to different data sources. Therefore, a RelQueryTable can join tables from different data sources.
A RelQueryTable includes a source table or feature class and a destination table or feature class. If you step through a cursor opened from a RelQueryTable, each row includes the columns from both input tables. The fields from the source appear on the left while the fields from the destination appear on the right. A row from each table is matched based on the primary and foreign keys from IRelationshipClass to produce a single row.
Shapes can only be retrieved from the source table. If the destination table has a geometry field, it will not be included in the RelQueryTable.
When you perform a join in ArcMap, a RelQueryTable object is created and used as the table or layer's data source for all display purposes. When in ArcMap, you can use the IDisplayTable::DisplayTable property to get a joined table or layer's RelQueryTable.
Since a RelQueryTable implements IObjectClass and IFeatureClass and inherits from Table, it can be treated like any other Table or FeatureClass. The IFeatureClass interface is implemented only when the source is a FeatureClass. A RelQueryTable cursor is read-only so you must edit the source and destination to change the data.
A RelQueryTable is designed to work with relationships that have a one-to-one or a many-to-one cardinality. If the cardinality is one-to-many, a row from the source will be associated with the first matching row in the destination and any other matching rows are ignored. A RelationshipClass with a many-to-many cardinality is not supported and will cause an error. If the relationship has a cardinality of one-to-many or many-to-many, use RelationshipClass objects to access the data. If the cardinality is really one-to-one, but the Relationship is defined as one-to-many, the RelQueryTable will still process correctly.
A RelQueryTable will have an ObjectID if the source has an ObjectID. When initialized, the RelQueryTable uses the values from the source's ObjectID field to define its ObjectIDs. If the source is a non-ObjectID object class, the RelQueryTable can still access the data, but there will be limitations such as an inability to select rows.
ObjectIDs by definition must be unique. The reason relationships with one-to-many cardinalities match one row from the source to only one row in the destination is to prevent repeating ObjectIDs in the RelQueryTable. Repeating ObjectIDs will cause many objects like SelectionSets and table windows to behave incorrectly.
Working with Events
When working with RelQueryTable's default outbound interface in Visual Basic 6 declare variables as follows: Private WithEvents pRelQueryTable as RelQueryTable