Question

I am using SSIS with VS2010 (shell) and databases going from SQL Server 2005 (32 bit)to SQL Server 2012 (64 bit). I am developing directly on the destination server (not optimal, but it works).

When I try to use the Transfer database task, it gives me an error message as follows:
“Error: The Execute method on the task returned error code 0x80131500 (An error occurred while transferring data. See the inner exception for details.). The Execute method must succeed, and indicate the result using an “out” parameter.”

Here is the problem… how do I view an “inner exception”?? it is a GUI interface with no way to step through the code! I even tried setting up logging – it just logs the same useless error message.

Microsoft has no information for this error code in their reference docs (that I could find).

After googleing the error code, I saw others have this error code along with messages having to do with users, roles, and creating them.

• I double checked that I have sysadmin rights on both servers, and
  logins on both.
• I tried the same Transfer Database task from each
  server to itself (with changeing database name) and that worked
  fine for both by themselves.
• I tried both DatabaseOnline and DatabaseOffline options. (same error both ways)
• I tried doing a “Transfer Logins” task before doing the transfer database task, that task worked, but not the Transfer databases task. Then it started throwing errors saying that the databases don’t exist – which implies that I need to transfer logins AFTER I transfer databases.

Here are my settings:

What am I doing wrong? OR how can I get the “inner exception” message?

Also, follow my post to Microsoft’s forums here:
http://social.technet.microsoft.com/Forums/en-US/sqlintegrationservices/thread/cda53c80-8da6-4ed1-898a-9f3ff8464ae2

Answer 1

This answer makes me sick to my stomach… I hope I save someone else this hassle. The problem was this:

1. First and foremost: the error message was not descriptive enough. The error should be handed to the interface.
2. Under “edit” on a “Transfer Database” task, the destination file paths are “auto-populated” with the file paths of the source database. They look right at first (and second, and third…) cursory glance. Upon further inspection the file paths were wrong. This makes sense if you are going from version to version – the folders are named with subtle differences according to version (MSSQL.1 vs. MSSQL11.<instanceName>).

In summary, the error was caused by the folder not existing because the path was set wrong. I imagine other low-level exceptions like this are also eaten by the interface with the same cryptic error message.