AO批量处理的经验之谈
AO批量处理的经验之谈
文章分类:Java编程往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对象,以解除对某个表的独占状态。
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对象,以解除对某个表的独占状态。