写个存储过程向临时表中插入数据,并从临时表中返回数据,在PL/SQL Developer中测试没问题,但用ASP.NET应用程序获取数据时出现:ORA-08103: object no longer exists 错误提示。
后来,把临时表的创建选项由 on commit delete rows改为on commit preserve rows; 解决!
但是,问题总出在“但是”上 :)
在ASP.Net页中查询临时表数据时,每查一次都要多出一些重复记录,原因肯定是Oracle的会话连接没有结束,导致每次执行存储过程都要先插入记录。Oracle会话为什么没有结束,肯定是ASP.NET服务程序在数据连接池中保持着与数据库的连接。但是为了性能我们也不能不用连接池。这样基于Oracle 会话的临时表是不能用了。
重新回到基于Oracle事务的临时表,也就是临时表的创建选项用on commit delete rows。然后,在ASP.Net应用程序中调用ODP自身的事务处理机制,问题得以解决!
注:
(1)理论上,不要在存储过程中执行Commit,即不要在存储过程中使用PL/SQL的事务处理, 否则ASP.NET页面也无法得到数据,因为commit 后,临时表中数据会自动清空。
(2)理论上,不用ODP的话,用OLEDB或微软提供的ORACLE事务处理机制应该也可以,我没有测试。
后来,把临时表的创建选项由 on commit delete rows改为on commit preserve rows; 解决!
但是,问题总出在“但是”上 :)
在ASP.Net页中查询临时表数据时,每查一次都要多出一些重复记录,原因肯定是Oracle的会话连接没有结束,导致每次执行存储过程都要先插入记录。Oracle会话为什么没有结束,肯定是ASP.NET服务程序在数据连接池中保持着与数据库的连接。但是为了性能我们也不能不用连接池。这样基于Oracle 会话的临时表是不能用了。
重新回到基于Oracle事务的临时表,也就是临时表的创建选项用on commit delete rows。然后,在ASP.Net应用程序中调用ODP自身的事务处理机制,问题得以解决!
注:
(1)理论上,不要在存储过程中执行Commit,即不要在存储过程中使用PL/SQL的事务处理, 否则ASP.NET页面也无法得到数据,因为commit 后,临时表中数据会自动清空。
(2)理论上,不用ODP的话,用OLEDB或微软提供的ORACLE事务处理机制应该也可以,我没有测试。