I am trying to read a csv file straight into a set of new feature classes within a new file geodatabase, but I am getting the following stack trace when it fails:
Attempted to read or write protected memory. This is often an indication that other memory is corrupt. ESRI.ArcGIS.Geodatabase at ESRI.ArcGIS.Geodatabase.IFeatureDataset.CreateFeatureClass(String Name, IFields Fields, UID CLSID, UID EXTCLSID, esriFeatureType FeatureType, String ShapeFieldName, String ConfigKeyword) at WaterEditorExtension.Model.SurveyUtilities.StreamWriting(String pointtype, String outfile, String[] record, IWorkspace workspace) in C:\Documents and Settings\lbadgerow\My Documents\Visual Studio 2008\Projects\WaterEditorExtension\WaterEditorExtension\Model\SurveyUtilities.cs:line 206.
I believe that it is related to a schema lock, but I am able to create a feature dataset which is confusing. (In proper stacktrace form, below is my workspace factory call, and my where I'm building the FC)
public IWorkspace CreateFileGdbWorkspace(String path, String jobnumber)
{
Type factoryType = Type.GetTypeFromProgID("esriDataSourcesGDB.FileGDBWorkspaceFactory");
IWorkspaceFactory workspaceFactory = (IWorkspaceFactory)Activator.CreateInstance(factoryType);
IWorkspaceName workspaceName = workspaceFactory.Create(path, jobnumber, null, 0);
IName name = (IName)workspaceName;
IWorkspace workspace = (IWorkspace)name.Open();
return workspace;
}
...
IFeatureWorkspace featwork = (IFeatureWorkspace)workspace;
featwork.CreateFeatureClass("test", outfields, CLSID, null, esriFeatureType.esriFTSimple, "SHAPE", "");
EDIT 17 March 2011: has anyone attempted to Thread a component (extension) of ArcMap? I'm thinking that I could release the schema lock that is preventing this from moving on to the FC creation phase of this project, but I can't seem to get ArcMap to remain stable when I create a new thread to build the gdb.
IList<T>
andICollection<T>
supposedly lead to your issue? While I believe it highly unlikely that these .NET Framework interfaces or the implementing classes are broken in any way (since they are so crucial and thus very well-tested), if indeed they cause problems during COM interop, it would be extremely helpful to know about it!