Provides access to the associated query definition.
Members
Name | Description | |
---|---|---|
CopyLocally | Indicates if the data must be copied locally. | |
PrimaryKey | The primary key field names. | |
QueryDef | QueryDef of feature class name. |
IQueryName2.CopyLocally Property
Indicates if the data must be copied locally.
Public Property CopyLocally As Boolean
public bool CopyLocally {get; set;}
Remarks
By default, CopyLocally is set to False.
IQueryName2.PrimaryKey Property
The primary key field names.
Public Property PrimaryKey As String
public string PrimaryKey {get; set;}
Remarks
The name of the field or fields to use for assigning Object ID's to the rows in the QueryDef. Provide a comma delimited string of field names for cases where more than one field is needed to provide a unique value for each row (i.e. composite keys)
Always provide fully qualified field names.
Inherited Interfaces
Interfaces | Description |
---|---|
IQueryName | Provides access to the associated query definition. |
Classes that implement IQueryName2
Classes | Description |
---|---|
FeatureQueryName | Esri Feature Query Name object. |
TableQueryName | Esri Table Query Name object. |
Remarks
This interface extends the IQueryName interface to allow Objects in tables created from a QueryDef. The table used in the QueryDef does not need to be registered with the geodatabase in order for the table generated from the QueryDef to have Object ID's. An Object ID column is required for a table to support selections. If the QueryDef includes a geometry column, a FeatureClass is created when the name object is opened.
How the PrimaryKey and CopyLocally properties are set determines whether or not the table will have an Object ID column. The following describes the various scenarios:
- If the PrimaryKey property is set, the field or fields indicated will be used to generate Object ID's regardless of how CopyLocally is set.
- If a column in the QueryDef is an Object ID column, this will be used as the PrimaryKey if the QueryDef involves a single table. The Object ID is used even if the PrimaryKey is set to another column. This happens regardless of how the CopyLocally property is set.
- In all other cases, the CopyLocally property is used to determine the course of action. If CopyLocally is True, then the rows returned from the QueryDef are copied to a local file and assigned an Object ID values. If CopyLocally is False, the data is accessed directly from the database and the rows will not have Object ID's.
There are three ways in which Object ID's are assigned to a table:
Direct - The values from the primary key field are used directly as Object ID's. Here the primary key must be a single field and of integer type.
public void IQueryName2_Direct(IWorkspace workspace)
{
IFeatureWorkspace featureWorkspace = (IFeatureWorkspace)workspace;
IQueryDef queryDef = featureWorkspace.CreateQueryDef();
queryDef.SubFields = "*";
queryDef.Tables = "parcels, house_listings";
queryDef.WhereClause = "parcel.parcel_id = house_listing.parcel_id";
//Direct
IQueryName2 queryName2 = new TableQueryNameClass();
queryName2.PrimaryKey = "parcel.parcel_id";
queryName2.QueryDef = queryDef;
}
Wrapped - The primary key values are mapped to unique integer values which are used as the Object ID's. The primary key in this case is set to a list of fields (i.e. composite keys) or a single non-integer field. Two mapping tables are created in memory (Object ID-> PrimaryKey, PrimaryKey-> Object ID). If the tables are too large to fit in memory, virtual memory will be used.
public void IQueryName2_Wrapped(IWorkspace workspace)
{
IFeatureWorkspace featureWorkspace = (IFeatureWorkspace)workspace;
IQueryDef queryDef = featureWorkspace.CreateQueryDef();
queryDef.SubFields = "*";
queryDef.Tables = "parcels, house_listings";
queryDef.WhereClause = "parcel.parcel_id = house_listing.parcel_id";
//Wrapped
IQueryName2 queryName2 = new TableQueryNameClass();
queryName2.PrimaryKey = "parcel.rout_id, parcel.parcel_id";
queryName2.QueryDef = queryDef;
}
Copy - No primary key is set and CopyLocally is set to True. In this case, the table is copied into the scratch workspace and an Object ID field is appended. The scratch workspace is usually under your system temp directory in a file named mx<n>.mdb.
public void IQueryName2_Copy(IWorkspace workspace)
{
IFeatureWorkspace featureWorkspace = (IFeatureWorkspace)workspace;
IQueryDef queryDef = featureWorkspace.CreateQueryDef();
queryDef.SubFields = "*";
queryDef.Tables = "parcels, house_listings";
queryDef.WhereClause = "parcel.parcel_id = house_listing.parcel_id";
//Copy
IQueryName2 queryName2 = new TableQueryNameClass();
queryName2.PrimaryKey = "";
queryName2.CopyLocally = true;
queryName2.QueryDef = queryDef;
}
With copy tables, the fields are renamed (A.field1-> A_field1), but the qualified name is still the alias name.
If you are working with feature classes use FeatureQueryName rather than TableQueryName.
The following diagram illustrates how the criteria described above is used to generate tables from TableQueryNames and FeatureQueryNames:
There are three ways in which Object ID's are assigned to a table:
Direct - The values from the primary key field are used directly as Object ID's. Here the primary key must be a single field and of integer type.
Wrapped - The primary key values are mapped to unique integer values which are used as the Object ID's. The primary key in this case is set to a list of fields (i.e. composite keys) or a single non-integer field. Two mapping tables are created in memory (Object ID-> PrimaryKey, PrimaryKey-> Object ID). If the tables are too large to fit in memory, virtual memory will be used.
Copy - No primary key is set and CopyLocally is set to True. In this case, the table is copied into the scratch workspace and an Object ID field is appended. The scratch workspace is usually under your system temp directory in a file named mx<n>.mdb.
With copy tables, the fields are renamed (A.field1-> A_field1), but the qualified name is still the alias name.
If you are working with feature classes use FeatureQueryName rather than TableQueryName.
The following diagram illustrates how the criteria described above is used to generate tables from TableQueryNames and FeatureQueryNames: