Third Tier » SQL Server 2008 http://www.thirdtier.net Support for IT Professional Wed, 01 Feb 2012 17:12:00 +0000 en hourly 1 http://wordpress.org/?v=3.0.4 Watch Out For SSIS Package Migration/Upgrade Errors http://www.thirdtier.net/2011/06/watch-out-for-ssis-package-migrationupgrade-errors/ http://www.thirdtier.net/2011/06/watch-out-for-ssis-package-migrationupgrade-errors/#comments Sun, 19 Jun 2011 03:09:00 +0000 edwin http://www.thirdtier.net/?guid=694ec2fb4f1890dc3a34419947104acc After successfully upgrading a multi-instance SQL Server 2005 Failover Cluster to SQL Server 2008 R2, I got woken up today by a page from a SQL Server Agent job failure. Knowing that the job was created by one of my colleagues, I ignored it for a while since it only runs once a week and is not really that critical since it only performs tasks for reporting purposes. However, I just can't seem to get it off my head that what seems to be a successful upgrade caused some issues on the SQL Server Integration Services (SSIS) components. I checked the SQL Server Agent Job History for more information but only found this bit of information in the error log

The package failed to load due to error 0xC0010014

After a quick search on Google, I found this blog post on the MSDN Blogs site that explains what could be a possible cause for the error. While the blog post defined a different error number from the one I had, I was sure that this was it. Knowing that I had SQL Server 2005 Failover Cluster before, I had a feeling that the DTExec.exe executable file was still hanging around. True enough, I saw the EXE file. And the SQL Server Agent job that failed points to the old version of the DTExec.exe file. I immediately changed the path from within the SQL Server Agent job to point to the new version of the DTExec.exe file. The command which points to the old path looks like this

C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe

After modifying the path, I now have this

C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTExec.exe

One thing to look for after upgrading a SQL Server 2005 instance to SQL Server 2008/R2 (whether it is a failover cluster instance or not) is to make sure that your SSIS packages are reconfigured to point to the new path of the DTExec.exe executable and test them accordingly 
]]> http://www.thirdtier.net/2011/06/watch-out-for-ssis-package-migrationupgrade-errors/feed/ 0 Watch Out For SSIS Package Migration/Upgrade Errors http://www.thirdtier.net/2011/06/watch-out-for-ssis-package-migrationupgrade-errors-2/ http://www.thirdtier.net/2011/06/watch-out-for-ssis-package-migrationupgrade-errors-2/#comments Sun, 19 Jun 2011 03:09:00 +0000 edwin https://www.thirdtier.net/?guid=694ec2fb4f1890dc3a34419947104acc After successfully upgrading a multi-instance SQL Server 2005 Failover Cluster to SQL Server 2008 R2, I got woken up today by a page from a SQL Server Agent job failure. Knowing that the job was created by one of my colleagues, I ignored it for a while since it only runs once a week and is not really that critical since it only performs tasks for reporting purposes. However, I just can't seem to get it off my head that what seems to be a successful upgrade caused some issues on the SQL Server Integration Services (SSIS) components. I checked the SQL Server Agent Job History for more information but only found this bit of information in the error log

The package failed to load due to error 0xC0010014

After a quick search on Google, I found this blog post on the MSDN Blogs site that explains what could be a possible cause for the error. While the blog post defined a different error number from the one I had, I was sure that this was it. Knowing that I had SQL Server 2005 Failover Cluster before, I had a feeling that the DTExec.exe executable file was still hanging around. True enough, I saw the EXE file. And the SQL Server Agent job that failed points to the old version of the DTExec.exe file. I immediately changed the path from within the SQL Server Agent job to point to the new version of the DTExec.exe file. The command which points to the old path looks like this

C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe

After modifying the path, I now have this

C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTExec.exe

One thing to look for after upgrading a SQL Server 2005 instance to SQL Server 2008/R2 (whether it is a failover cluster instance or not) is to make sure that your SSIS packages are reconfigured to point to the new path of the DTExec.exe executable and test them accordingly 
]]> http://www.thirdtier.net/2011/06/watch-out-for-ssis-package-migrationupgrade-errors-2/feed/ 0 Installing SQL Server 2008 Failover Cluster on a Windows Server 2008 R2? http://www.thirdtier.net/2009/12/installing-sql-server-2008-failover-cluster-on-a-windows-server-2008-r2/ http://www.thirdtier.net/2009/12/installing-sql-server-2008-failover-cluster-on-a-windows-server-2008-r2/#comments Mon, 28 Dec 2009 18:47:00 +0000 edwin I did a demo fest on installing SQL Server 2008 Failover Cluster on a Windows Server 2008 system a few weeks back for a user group event and the attendees requested that I post more information about how to do a slipstream of service pack in a SQL Server 2008 installation. With Windows Server 2008 R2 already released, Microsoft released KB article 955725 highlighting the need for SQL Server 2008 Service Pack 1 when installing on either Windows 7 or Windows Server 2008 R2. I wrote an article on MSSQLTips.com about it to supplement the series on installing SQL Server 2008 Failover Cluster.

This blog post came a bit late as I needed to wait for the article to be posted on the site so I can use it as a reference.
]]> http://www.thirdtier.net/2009/12/installing-sql-server-2008-failover-cluster-on-a-windows-server-2008-r2/feed/ 0