This document is archived and information here might be outdated.  Recommended version.


RelQueryTable CoClass (ArcObjects .NET 10.6 SDK)
ArcObjects Help for .NET developers > ArcObjects namespaces > Geodatabase > ESRI.ArcGIS.GeoDatabase > Classes > R > RelQueryTable CoClass (ArcObjects .NET 10.6 SDK)
ArcObjects Library Reference (GeoDatabase)  

RelQueryTable CoClass

An object that joins two datasets based on common data values.

Product Availability

Available with ArcGIS Engine, ArcGIS Desktop, and ArcGIS Server.

Supported Platforms

Windows, Solaris, Linux

Interfaces

Interfaces Description
IClass Provides access to members that return information about and manage the class.
IConnectionPointContainer (esriDisplay)
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.
IObjectClassEvents Provides access to events that occur with 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.

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.

See Also

IFeatureClass Interface | ITable Interface