May 17, 2012 at 7:56 am
I've been asked to run a package on a sql server - its Enterprise Edition (64-bit), SQL Server 2008. The compatibility level of the database is SQL Server 2005. The package was provided by a consultant off site. I copied the package on to the server - placing it in the directory where it could be seen by SSMS integration services.
My experience with SSIS is limited.
A few questions:
1. Copying to a directory where it can be seen by SSMS integration services - is there a better
method to employ to run the package?
2. This is Enterpise Edtion 64 bit - is there a requirement to run this from a command prompt as
opposed to running through the "Execution Package Utility"? I believe in 2005 - running
through the UI was 32 bit vs running command prompt you can convert to 64 bit. Is my concern
here justified? Am I confusing this with something else?
Any comments / URLs provided would be appreciated. Thanks.
May 18, 2012 at 7:18 am
In the directory tree of the sql server, there are two directories for Program Files, 'Program Files' and 'Program Files (x86)'. It refelects 64 bit ('Program Files') or 32 bit ('Program Files (x86)'). In each tree you will find DTEXEC and DTEXEC.exe. Invoking this will start the Execution Package Utility. I questioned the vendor about what is invoked within SSMS - he believed it was 64 bit. That said I ran the utility through SSMS SSIS and the package ran successfully. That resolved one concern however I'd still like to know more about running in command prompt.
Hope this helps...
June 25, 2012 at 12:23 pm
I believe that the 64bit version of DTEXEC gets hit first if you are not specific on the file path. With that said here is a link to a good explanation on running thru DTEXEC plus using SQL Job to run also.
http://technet.microsoft.com/en-us/library/ms138023(v=sql.110).aspx
Hope this helps
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply