I've been battling a peculiar issue for a couple of days regarding Data Transformation Services (DTS) with SQL Server 2000 and SQL Server 2005.
I wrote a small C# application that utilizes DTS to pull a database from a server down to a client machine. All in all, the application runs beautifully and the information synchronizes seamlessly. Occasionally, however an odd error was reported: Unable to connect to source server for Transfer. This was odd because all of my connections were succeeding. It was also only on this computer that the error was occurring - I could not duplicate the error on other computers so I began delving into the differences between the machines.
As it turns out, the error has to do with mismatched database versions which I've whittled down to the following matrix:
| Client SQL Version | Server SQL Version | Result |
| MSDE | SQL Server 2000 | No Issues |
| SQL Express | SQL Server 2000 | No Issues |
| MSDE | SQL Server 2005 | FAILS |
| SQL Express | SQL Server 2005 | No Issues |
As you can tell, the issue arises when the client database engine is not at least as high as the server version. I'd long suspected that a version mismatch was the root of the problem but hadn't ascertained it until today. After troubleshooting this for some time to make sure that there wasn't something else I was missing, I ran a trace on the SQL Server to detect whether something was happening there. (I had actually run the same trace before but failed to see the key piece of information).
The DTS transfer objects apparently have baked into them a version check. When run from an MSDE client it performs the following query:
if (object_id('master.dbo.sp_MSSQLDMO80_version') is not null) exec master.dbo.sp_MSSQLDMO80_version else if
(object_id('master.dbo.sp_MSSQLDMO70_version') is not null) exec master.dbo.sp_MSSQLDMO70_version else select 0
SQL Server will always return a valid result set for the current version (e.g. 2005 returns valid results if the sp_MSSQLDMO90_version sproc is called and 2000 returns correctly if the sp_MSSQLDMO80_version sproc is called), but will throw and exception on any other version's sproc. The issue is that the MSDE will check for sp_MSSQLDMO80_version on a SQL2005 box which returns an error which ultimately cascades down and cancels the DTS package.
From a SQL Express client, the query is this:
if (object_id('master.dbo.sp_MSSQLDMO90_version') is not null) exec master.dbo.sp_MSSQLDMO90_version else if
(object_id('master.dbo.sp_MSSQLDMO80_version') is not null) exec master.dbo.sp_MSSQLDMO80_version else if
(object_id('master.dbo.sp_MSSQLDMO70_version') is not null) exec master.dbo.sp_MSSQLDMO70_version else select 0
In this case, the query will continue to work against a SQL2005 server or a SQL2000 server.
In other words, SQL is throwing the 'cannot connect' error correctly. Internally it reports "To connect to this server you must use SQL Server Management Studio or SQL Server management Objects (SMO)".
Solution:
My application must maintain full compatibility with the MSDE -> 2000 environment. The only solution I could come to was that in order for my application to run against a SQL Server 2005 server the client computer would have to be upgraded to SQL Express. I hate to have to do that, but I could see no other viable solution.
Are there other thoughts out there?