Hi @all,
we've got a problem with importing invoices into our database. There are 2 to 4 workstations that import between 10 and 5000 invoices into a table structure like this: Invoice - Items - Person - Errors. The problem is that somateimes there are Application deadlocks and an entire set of invoices has to be imported again.
For importing we use: Team Developer 4.1 Build 13821. - Isolation Level "RL" - Create Session - Call SqlSetParameter( r_hSql, DBP_PRESERVE, TRUE, STRING_Null ) - Call SqlSetParameter( r_hSql, DBP_AUTOCOMMIT, FALSE, STRING_Null )
Is there any way to make use of the DBP_LOCKWAITTIMEOUT constant in this cause?
Thanks for your help
9.0.1 - TD 2005.1 - Multiuser problem
Re: 9.0.1 - TD 2005.1 - Multiuser problem
Hi Don,
This would probably be best responded to if you put it in the Team Developer 5.2 and older forum in the Older Releases subforum. I can move it there for you if you want or you can duplicate it. Just let me know.
Best regards,
This would probably be best responded to if you put it in the Team Developer 5.2 and older forum in the Older Releases subforum. I can move it there for you if you want or you can duplicate it. Just let me know.
Best regards,
Re: 9.0.1 - TD 2005.1 - Multiuser problem
I don't think that increasing a timeout value can be helpful in a deadlock situation.
In a deadlock 2 application uncommited access tablesin a reverse order so that one application blocks the other. This situation can be detected immediately and will not become better if you wait some time. The transaction in one application needs to be rolled back so that the other application can continue it's transaction. The deadlock error does exactly this.
What you can do to avoid deadlocks:
- make your transactions as short as possible
- acces the tables in the same order in both applications
- avoid circles in accessing tables without making a commit between
- use another database management system
(SQLBase has additional internal deadlocks,
which also occur if you only use select commands
(with joins, unions or long varchar columns))
Regards,
Rainer
In a deadlock 2 application uncommited access tablesin a reverse order so that one application blocks the other. This situation can be detected immediately and will not become better if you wait some time. The transaction in one application needs to be rolled back so that the other application can continue it's transaction. The deadlock error does exactly this.
What you can do to avoid deadlocks:
- make your transactions as short as possible
- acces the tables in the same order in both applications
- avoid circles in accessing tables without making a commit between
- use another database management system
(SQLBase has additional internal deadlocks,
which also occur if you only use select commands
(with joins, unions or long varchar columns))
Regards,
Rainer
Who is online
Users browsing this forum: No registered users and 0 guests