Opening a dataset such as a table or a feature class from a geodatabase can be an expensive operation. With this in mind, application developers should try to minimize the number of times they open datasets by following these patterns:
Keep datasets from going out of scope: If a dataset is being opened in a method that gets called frequently, consider keeping a reference to the dataset outside of the method to keep it from going out of scope and forcing the application to reopen it each time the method is called.
The code below shows an example of how this might look before and after:
public void MyMethodBefore()
IFeatureClass featureClass = featureWorkspace.OpenFeatureClass(“Parcels”);
private IFeatureClass parcelsClass = null;
// Call this prior to calling methods that use the parcels class.
public void Initialize()
parcelsClass = featureWorkspace.OpenFeatureClass(“Parcels”);
public void MyMethodAfter()
// Use the parcels class …
Of course, this will apply a shared schema lock to the feature class so it may not be appropriate for all applications.
Open related classes when notification is used: Whenever an application is editing a dataset and that dataset participates in a relationship class with notification, it’s related dataset should also be kept open. Consider a Parcels-Owners relationship class that has forward notification enabled; whenever a parcel is created, deleted or modified, a message is sent to the Owners class. If the Owners class is not open it will be opened by the system. The geodatabase must do this because a response to the message may occur (i.e. deleting an owner in response to the deletion of a parcel, for composite relationships). After a class is opened by the geodatabase it will be closed.
Application developers can prevent this kind of performance hit by simply opening the related class at the same scope as the class being edited. How much this improves performance depends on many factors, but a ten-fold increase is not atypical, and fifty-fold increases have occurred.