>>please, somone guide me where i am wrong >> >> This support list is for the Firebird database. For the .NET >> providers, you need to subscribe to the firebird-net-provider list: >> List-Subscribe: >> <https://lists.sourceforge.net/lists/listinfo/firebird-net-provider>, >> >At first glance it sounds like a lock conflict with a wait transaction, which >is not specific to .net. >To me this list would seem to be better unless and until it requires .net >provider specific information.
If it is a lock conflict, then the process would hang on one out of 100 000 records. Using wait transaction(s) for batch processing of 100 000 records may not be a good idea, in most cases it would be better to return back some error in a log and continue processing those records that succeed. Though we don't yet know whether or not it is a lock conflict. I'd recommend Sukhen to change from WAIT to NO WAIT (if this is an issue) and if this doesn't help, to give us further information: Does the update process successfully process some record before taking extremely long on one record? Does the update process sometimes succeed within minutes or an hour or two, but then suddenly take over 10 hours? Are you constructing a new query for every insert/update and use 100000 transactions or even connections, or do you have one UPDATE OR INSERT statement using parameters all running inside the same transaction (or even declaring an external table for the import)? Set
