Subject | Re: [firebird-support] Hang On ExecuteNonQuery Using Firebird2.5 with visual studio 2010 |
---|---|
Author | SUKHEN DASS |
Post date | 2015-02-23T09:54:20Z |
have checked with wait and no wait both dint work could you please, how to set wait/no wait in back end i.e. in firebird database .I have set in front end for TransactionBehavior class wait/no wait & both dint work
On Monday, February 23, 2015 3:22 PM, SUKHEN DASS <sukhendass@...> wrote:
update never fails but it fails in insert query. loop run in a single connection with a new datarows in same query.
On Monday, February 23, 2015 2:51 PM, "Svein Erling Tysvær svein.erling.tysvaer@... [firebird-support]" <firebird-support@yahoogroups.com> wrote:
>>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