Porting Database app from VC++ 6 to VS 2005 - locking issues



  •  I have moved a SQL server app written in VC++6 to VS2005(made up of 44 projects, each one a COM dll) - it all works as it should except for one thing. In the VC6 version there is a dll which does a fair bit of repetitive locking & updating.It runs quickly. When the same code is run under VS2005 there is a ReadOnly ADO SELECT statement on a table which is already locked pessimistically which waits for a LockTimeout before it continues which causes it to run much slower. As far as I can tell this is correct behaviour, however the VC6 version did not wait for the lock to timeout even though it looks like it should. I'm now worried that there may be many more undiscovered locking WTFs in the old code that one could "get away with" in VC6 but now no longer work. I've already encountered other C++ code in the VC6 version which "shouldn't have worked " but did and needed correcting in VS2005.

    My question is - does anyone know of reasons why the same version of ADO would behave differently under  VC6 to VS2005? or does anyone know if it behaves differently even if you don't know why?



  • Could be because 2005 no longer supports the single-threaded runtime?



  • Can you post a snippet of your code so I can have a look-see?



  • I'll try to cobble something together that explains it better- its the kind of app that uses lots of different COM dlls &  has fairly lengthy database transactions 



  • @mfah said:

    Could be because 2005 no longer supports the single-threaded runtime?
     

    Could you expand upon that at all? Any change from 6.0 to 2005 is a good candidate... 



  • @method1 said:

    @mfah said:

    Could be because 2005 no longer supports the single-threaded runtime?
     

    Could you expand upon that at all? Any change from 6.0 to 2005 is a good candidate... 

    You can read about it here, and the official line on it here

    I'm guessing (and I emphasize "guessing") that if you were linking with the single-threaded CRT in version 6, any threading-related issues you may have previously had but which would not have been evident during testing/debugging may suddenly blow up in your face. I've seen it happen with other apps I've moved from 6 or 2003 to 2005 or 2008. If not, either of those pages might indicate other likely candidates.


Log in to reply