AO批量处理的经验之谈

往Personal GDB或SDE GDB中写入要素记录是一件非常简单的事情，但似乎太多的情况下，写入数据的用例过于简单，使得许多代码问题、特别是ArcSDE本身的问题和Error 无法暴露，很多人也从未意识到类似的问题。我最近正在做类似的工作，代码编写似乎不难，但测试就要了命了，发现的问题数不胜数，头痛不已。

1.插入记录的效率问题
向要素类中插入记录有两种方式，一是IFeature.Store，另一个是IFeatureCursor.Insert(IFeatureBuffer)和IFeatureCursor.Flush方法，显而易见的，后一种方法由于使用了缓存，速度上比前者快。

2.往MDB和SDE要素类中插入记录
这两种类型的要素类在往其中插入数据时不一定需要使用IWorkspaceEdit接口来开启和关闭一个Session，但是，如果SDE的要素类被注册为 version，这个接口就必须使用了，否则CPU会高达100%，并会爆出“the operation in invalid on a closed state”的错误。而使用了有版本的SDE要素类，我遇到了许多令人崩溃的SDE ERROR，比如FDO_E_SE_DB_IO_ERROR、FDO_E_SE_OUT_OF_LOCKS等等。

3.将多个MDB导入一个MDB的时候，如果使用了IWorkspaceEdit接口，会出现某几个图层无法用ArcMap或ArcCatalog打开的情况，即以打开程序就崩溃，而不是用该接口，其它相同的代码做的加载过程，一切正常。

4. 将两个或以上MDB导入一个MDB时候，到第二个MDB，很可能发生“**_SHAPE_INDEX被占用”的情况，这是因为写.NET平台代码时，你遍历或插入数据的游标cursor未释放的缘故。pFeatureCursor=null;并不会将对象从内存中清除，这是因为.NET平台是由 Runtime来收集垃圾的，不像VC或VB那样能直接销毁COM对象，此时你应该使用 System.Runtime.InteropServices.Marshal.ReleaseComObject方法来强制释放COM对象，以解除对某个表的独占状态。