关于释放SDE连接的问题

如果我们尝试往SDE中使用AO代码加载大量的数据，比如每个图层50万条记录，一共30个图层，那么这个过程是个不折不扣的噩梦，你会遇到许多匪夷所思的问题，一般而言，出了问题总是会报个fdoerr号，我们也可以查一查，但如果出现的问题号属于SDE ERROR类型，就不好说了，你会发现某些情况整个网络上都没有看到过，就是一个孤例。比如我遇到过的FDO_E_SE_DB_IO_ERROR和FDO_E_SE_OUT_OF_LOCKS等。

我在往SDE中写代码导入数据时候频繁遇到FDO_E_SE_DB_IO_ERROR问题，尽管safe网站上给出了该问题的三种可能原因，但我一直都没能从Oracle的角度解决。统计一下往SDE导入数据成功的情况，每次导入一个要素类，即每个要素类导入时都给开启一个专用的gsrvr进程，成功率是最高的，几乎为95%。 不成功的10%是一次导入200万条标注要素类，但分开岛，每次50万条，也一切安好。

那么问题就来了，我们知道，SDE安装后，SDE与DBMS之间有一个giomgr进程负责管理双方的通讯过程，即根据访问请求建立gsrvr进程。一般地，gsrvr将处理与SDE有关的查询，存储，删除等操作，并且它能处理多个连接请求，它与DBMS的关系就是“通则不痛，通则不痛”，一旦传输的数据量多了，gsrvr就开始抽风了。我们的问题是，如何让一个要素类处理完成后，释放这个连接，即关闭该 gsrvr进程，在下一个要素类开始时再次建立一个新gsrvr进程。这个方式的确也是最为保险的。

现在问题就是，如何释放SDE连接，事实上，如果使用纯COM对象来写，这几乎不是问题，有人认为将工作空间对象设置为null即可。比如我们写个VB的代码：

dim pFWS as IFeatureWorkspace
set pFWS=SdeWorkspaceFactory.open()   '1
set pFWS=nothing                                       '2

去看看Oracle的连接，在1执行完后，应该有两个SDE链接，而在执行完2以后，就只有一个SDE链接了，其所有者是giomgr。显然，SDE连接被关闭了。

那么在.NET平台中，这种set pFWS=nothing是行不通的，我们得使用

System.Runtime.InteropServices.Marshal.ReleaseComObject(pFWS);

才能让非托管代码在内存中被清除。试一试，也可以发现SDE的连接关闭。

将问题再复杂一点，如果我们遍历一次pFWS中的某个要素类，会发现即使使用

System.Runtime.InteropServices.Marshal.ReleaseComObject(pFWS);

也搞不定，解决的方法是，将你在代码中new出来的所有的AO对象都用

System.Runtime.InteropServices.Marshal.ReleaseComObject

方法释放，某些循环产生的对象，如：

pFeature=pFeatureCursor.NextFeature();
while(pFeature!=null)
{
     System.Runtime.InteropServices.Marshal.ReleaseComObject(pFeature);
     pFeature=pFeatureCursor.NextFeature();
}
System.Runtime.InteropServices.Marshal.ReleaseComObject(pFeatureCursor);

也必须销毁，如果有一个与SDE数据库相关的对象未销毁，则仍然存在两个SDE连接。

使用这种一个图层一个gsrvr进程的方法后，再未出现过FDO_E_SE_DB_IO_ERROR问题。