| Author |
Topic |
|
MrRenn
Starting Member
8 Posts |
 Posted - 2009-05-11 : 08:38:51
|
| HiI have an MFC application with explicit transaction handling. Within the transactions are CRecordSets used. ODBC is used to connect to a server (MSSQL 2000). The application is a COM-dll. Example:Begin transactionSave record AUpdatesSave record BCommit transactionThis must be executed in ONE transaction and the software has worked like this for years but now something strange is happening. In one installation every save and update come in different transactions that result in lock-timeouts. Then rollback fails to rollback everything, cause it's no longer one transaction. Any ideas of what can cause this? |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
|
|
MrRenn
Starting Member
8 Posts |
Posted - 2009-05-11 : 11:28:03
|
| I've used the SQL Profiler on two separated installations and compared the results. On the working installation everything is executed in a single transaction. In the failing one it's not. I don't get any errors or warnings but I do get a "look:timeout". After 15 seconds I get an "Attention" and then the code continues to execute. This happens twice and causes a timeout for the whole transaction at about 30 seconds into the whole transaction. If I could just change one of these two timeout values the transaction would probably pass through. |
 |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
|
|
MrRenn
Starting Member
8 Posts |
Posted - 2009-05-11 : 11:55:27
|
| The query timeout is set to 400 seconds in the code. It is something else that makes the transaction end at 30 seconds. |
|
|
|
MrRenn
Starting Member
8 Posts |
Posted - 2009-05-12 : 02:27:10
|
| The problem surfaced once before and then disappeared after some days. I really don't think it's the SQL Server, I think it's something else. |
|
|
|
MrRenn
Starting Member
8 Posts |
Posted - 2009-05-13 : 05:17:59
|
| It seems like this is not a problem with the application or the database. It must be something higher up. Can any restrictions from .NET or IIS effect the type of connection I get to the database in the COM application? |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
|
|
SwePeso
Patron Saint of Lost Yaks
30421 Posts |
Posted - 2009-05-13 : 14:35:57
|
Why are you suddenlt getting locks?
E 12°55'05.63"N 56°04'39.26" |
|
|
|
MrRenn
Starting Member
8 Posts |
Posted - 2009-05-14 : 13:44:05
|
quote:
Originally posted by Peso
Why are you suddenlt getting locks?
E 12°55'05.63"N 56°04'39.26"
You tell me! :) The same COM application in production for a year and suddenly it fails, not randomly but everytime at the exact same place. I don't know why my explicit transaction disappeared. |
|
|
|
MrRenn
Starting Member
8 Posts |
Posted - 2009-05-14 : 13:52:01
|
| What's even more strange is that I got it to work when I directly loaded the DLL from a test application. But it fails when the webservice loads the DLL using COM from the .NET application.I've used "Process explorer" to see if it's te right DLL that is loaded and the DLL is located in the right directory. I'm confused. |
|
|
|
LoztInSpace
Aged Yak Warrior
940 Posts |
Posted - 2009-05-17 : 03:39:20
|
| Sounds like someone has introduced a rogue 'commit' into a SP or something. Maybe logging?Or if COM+ is managing your transactions then someone could have flicked some switches.Have you checked your change control? |
|
|
|
MrRenn
Starting Member
8 Posts |
Posted - 2009-05-18 : 08:09:10
|
| I suspected the logging. The application logs into one table from triggers fired on update and insert on multiple tables. But then again, it used to work.I haven't found anything in the event viewer that indicates any strange changes. I've deleted the COM interface and then registered it again with what I think is the correct parameters, without any luck.I know that there were changes made to the network outside this application environment but I can't see how that would affect the IIS and the other applications inside the closed network. Is it possible that some permissions are in some way inherited from this network outside causing MSDTC, connection pooling or something else to not work properly? |
|
|
|
|
What used to be ONE transaction