Tag Archives: Intermediate
Geodatabase replication and compress
There is new documentation available which talks about some best practices when using the compress command while also employing geodatabase replication. Compress is a process run periodically by an ArcSDE administrator to reduce the size of the geodatabase and improve performance. Replicas in the ArcSDE geodatabase can affect the compress process. This paper describes best practices for achieving an effective compress when there are replicas.
It is recommended that you first have an intermediate understanding of ArcSDE, versioning and replication before reading the paper.
To have a look at the paper, click HERE
Geodatabase Essentials – Enterprise Geodatabases
Derek Law has written an article titled Enterprise Geodatabase 101 which was recently posted on ArcUser Online. The article provides a general overview of the enterprise geodatabase looking at key features, architecture, and implementation. It is geared towards GIS managers and database administrators.
The article is full of good info, you can check it out HERE
Developer Tips – Qualified field names in ArcSDE
This post was provided by geodatabase Product Engineer James MacKay.
There are fourteen field names that cause fields to behave slightly different in ArcSDE. They are:
|
AREA |
POINTS |
FID |
EMINX |
EMINY |
EMINZ |
MIN_MEASURE |
|
LEN |
NUMOFPTS |
ENTITY |
EMAXX |
EMAXY |
EMAXZ |
MAX_MEASURE |
These field names conflict with internal ArcSDE properties used for storing geometries. Fields that use these names can be created like any other fields, but when they’re retrieved – or when using FindField to find their indexes in a fields collection – they will be qualified with the username and table name (and database name, if applicable).
This means a field named “Len” could appear as “wgretzky.Highways.Len” if the DBMS is Oracle, or as “sde.mlemieux.Highways.Len” if the DBMS is SQL Server.
The best plan is to avoid using these field names, but when that isn’t possible, a few code changes can be made to handle these cases. The most noticeable effect is that calls to FindField with the unqualified field name will return a value of -1 (indicating that the field could not be found).
It’s the developer’s responsibility to either qualify the field name with the username and table name (and database name, if applicable), or to find the field’s index with IFields2.FindFieldIgnoreQualification (this will find both qualified and unqualified field names).
The code below shows how to retrieve a field with the FindFieldIgnoreQualification method:
private IField GetFieldByName(IWorkspace workspace,IObjectClass objectClass, String fieldName)
{
// Cast the workspace to the ISQLSyntax interface.
ISQLSyntax sqlSyntax =(ISQLSyntax)workspace;
// Get the field’s index from the fields collection.
IFields2 fields2 = (IFields2)objectClass.Fields;
int fieldndex = -1;
fields2.FindFieldIgnoreQualification(sqlSyntax, fieldName, out fieldIndex);
// If the field was found, return it.
if (fieldIndex >= 0)
{
return fields2.get_Field(fieldIndex);
}
else
(
return null ;
}
}
Developer Tips – Using the Field Checker
This post was written by geodatabase Product Engineer James MacKay. James works on the geodatabase development team and is responsible for a lot of the geodatabase SDK that is generated.
The IFieldChecker interface provides a way to validate fields for a specific workspace before they’re created. Reserved keywords, special characters and maximum field name lengths are properties that vary between different types of workspaces and DBMSs; the field checker will not only detect fields that violate these rules, but it will generate a “fixed” fields collection with a similar (but valid) name. There are three common cases where field checkers are useful:
- Creating new feature classes or tables
- Adding fields to existing datasets
- Generate target dataset fields for use in the feature data converter
A field checker should always be used whenever an application allows users to manually enter field names, but it’s a good defensive programming pattern to use them all of the time. The following code shows how to validate fields prior to a CreateTable or CreateFeatureClass call.
Geoprocessing users: The geoprocessor also exposes field checking capability. See this article for more information.
public IFields ValidateFields(IWorkspace workspace, IFields fields)
{
// Create and initialize a field checker.
IFieldChecker fieldChecker = new FieldCheckerClass();
fieldChecker.ValidateWorkspace = workspace;
// Generate a validated fields collection.
IFields validatedFields = null;
IEnumFieldError enumFieldError = null;
fieldChecker.Validate(fields, out enumFieldError, out validatedFields);
// You can either notify the user of any errors or just skip this step.
IFieldError fieldError = null;
while ((fieldError = enumFieldError.Next()) != null)
{
Console.WriteLine(“Error in field {0}: {1}”, fieldError.FieldIndex, fieldError.FieldError);
}
// Return the validated fields.
return validatedFields;
}

