为什么批量更新大约一分钟后FbDataAdapter会抛出NullReferenceException?
将包含 1850 左右新行的 DataTable 更新到 FbDataAdapter 时,我在执行期间收到 NullReferenceException。
通常它会成功插入大约 1200 条记录,有时更多,有时更少......
但是,当使用调试器单步执行代码时,它有时会插入整个记录集,没有问题。
我正在使用 Firebird ADO.NET DataProvider v2.1。
有什么想法吗?谢谢!
堆栈跟踪:
System.NullReferenceException was unhandled by user code Message="Object reference not set to an instance of an object." Source="FirebirdSql.Data.FirebirdClient" StackTrace:
at FirebirdSql.Data.FirebirdClient.FbDataAdapter.Update(DataRow[] dataRows, DataTableMapping tableMapping)
at System.Data.Common.DbDataAdapter.UpdateFromDataTable(DataTable dataTable, DataTableMapping tableMapping)
at System.Data.Common.DbDataAdapter.Update(DataTable dataTable)
at DBTools.MergeDB.DataAccess.DatabaseHelper.UpdateDataTable(Int32 connectionIndex, DataTable dataTable) in C:\Workspaces\DatabaseTools\Releases\Latest\Sources\DBTools\DBTools.MergeDB\DataAccess\DatabaseHelper.cs:line 74
内部异常:
When updating a DataTable with 1850-ish new rows to a FbDataAdapter I get a NullReferenceException during execution.
Usually it succeeds in inserting around 1200 records, sometimes more, sometimes less...
However when stepping through the code with the debugger, it sometimes inserts the entire recordset, no problem.
I am using the Firebird ADO.NET DataProvider v2.1.
Any ideas? Thanks!
StackTrace:
System.NullReferenceException was unhandled by user code Message="Object reference not set to an instance of an object." Source="FirebirdSql.Data.FirebirdClient" StackTrace:
at FirebirdSql.Data.FirebirdClient.FbDataAdapter.Update(DataRow[] dataRows, DataTableMapping tableMapping)
at System.Data.Common.DbDataAdapter.UpdateFromDataTable(DataTable dataTable, DataTableMapping tableMapping)
at System.Data.Common.DbDataAdapter.Update(DataTable dataTable)
at DBTools.MergeDB.DataAccess.DatabaseHelper.UpdateDataTable(Int32 connectionIndex, DataTable dataTable) in C:\Workspaces\DatabaseTools\Releases\Latest\Sources\DBTools\DBTools.MergeDB\DataAccess\DatabaseHelper.cs:line 74
InnerException:
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我找到了这个线程: http://osdir.com/ml /db.firebird.dotnetprovider/2006-04/msg00058.html
这可能会建议一个解决方案。
如果这对您不起作用,我建议您获取 Firebird 数据提供程序的源代码并查看其中,看看是否可以发现问题。如果没有,请尝试向导致问题的 Firebird 代码添加一些错误处理(例如,将异常记录到文本文件),然后编译该代码并使用它来代替当前的 Firebird.Data.dll(或任何名称)。
如果您可以隔离问题,那么您可以联系 Firebird 开发人员并让他们了解该问题...或者更好的是,提交修复!这样你就可以获得工作代码,并且可以回馈开源社区。
I found this thread: http://osdir.com/ml/db.firebird.dotnetprovider/2006-04/msg00058.html
which may suggest a solution.
If that doesn't work for you, I suggest grabbing the source of the Firebird data provider and having a look in there to see if you can spot the problem. If not, try adding some error handling (e.g. logging exceptions to a textfile) to the Firebird code that's causing the problem, then compile that code and use it instead of the current Firebird.Data.dll (or whatever it's called).
If you can isolate the problem, then you can contact the Firebird developers and let them know about it... or even better, submit a fix! That way you get working code and you get to give something back to the open-source community.
除了 Ian 的建议之外,我还会尝试新的 .Net Provider 2.5。
http://www.firebirdsql.org/index.php?op=文件&id=netprovider
Besides Ian's suggestions, I'd also try the new .Net Provider 2.5.
http://www.firebirdsql.org/index.php?op=files&id=netprovider
感谢您的建议!
经过一番研究后,我得出的结论是 NullReferenceException 是实际异常的副作用。基本上更新时间太长,大约60秒后超时。
我更改了连接字符串以允许事务(Enlist=true;),并在代码周围添加了一个 TransactionScope,超时时间为 TimeSpan.MaxValue:
这解决了问题......但是,我将研究 Firebird 客户端源代码实际异常(超时)未正确级联到调用者的原因。
Thanks for the suggestions!
After a bit of research I concluded the NullReferenceException was a side-effect of the actual Exception. Basically the update took too long, and timed out after about 60 seconds.
I altered the connection string to allow transactions (Enlist=true;) and added a TransactionScope around the code with a timeout of TimeSpan.MaxValue:
This solved the problem... I am, however, going to look into the Firebird Client source for the reason why the actual exception (timeout) is not correctly cascaded to the caller.