View Complete Post
I am trying to migrate our processing from command line based scripts and foxpro to SQL so IÃÂ need to run the SSIS packages using dtexec. I copied the dtexec file and a few dll's that are missing to our production servers but i cant execute the packages. I dont want to install the full client tools (particularly managment/business inteligence studio) on our production servers due to the overhead and limited system disk space.
Can somebody tell me what the minimum install would be so I would be able to run SSIS packages using the dtexec or dtexecui tools? I would also like to install some of the other command line client tools like osql etc.
When i am trying to execute the SSIS Package in BIDS, it works fine. When I schedule the same package as job in SQL Server Agent it gives the following error.
Here is the complete log information:
Log Job History (ssis)
Step ID 1
Job Name ssis
Step Name ssis
Sql Severity 0
Sql Message ID 0
Operator Net sent
Retries Attempted 0
Executed as user: NT AUTHORITY\NETWORK SERVICE. The package could not be found. The step failed.
i tried to run the job with proxy accounts also but it didnt work for me. Please help me.
I have developed a dtsx package to load data from xml load table into a dozen of flat tables. I found the SSIS is running slow (almost 10 times slower) under Execute Package Utility than running under visual studio IDE.
Does anyone have same experience?
When I attempt to run an SSIS package interactively in Visual Studio 2005, I am getting a different SSIS package from the same project opening in debug mode instead?
I had a similar issue on my old PC but as It was being replaced, I didn't worry too much but I now have the issue again. Please tell me there is someone else out there experiencing the same frustrating issue?
If I import the package I want to run to a new project then I can run it interactively but this is a pain of a work around.
Hi, multipart questions.
We have a SQL 2008 Cluster where we do not want to install SSIS. We have a SQL 2005 SSIS instance on another server for packages.
1. Can we configure jobs on the SQL 2008 custer to point to the 2005 SSIS instance? and do we need SSIS installed on the SQL 2008 cluster to do this?
2. Can we run jobs on a SQL 2005 instance, pointing to a SQL 2005 SSIS instance/packages on a third server that connect to a SQL 2008 DB instance . I know that sounds crazy, but where exactly is the CPU and memory load in that design.. job on one server,
package a seperate server and db on a third server.?
3. As mentioned, I have SQL 2005 SSIS instance. I have local admin on that server and can connect to the ssis instance from my sql 2005 sql client on my desktop. I added a new user to the server and added them to the SSIS and users group. I also
made sure they could write to the folder where they will deploy packages. However, they get some kind of access denied while trying to connect, unless I give them local admin on the server. What more access do they need than to be in the users and SSIS
group and have write access to an SSIS deployment folders?
On my local desktop, I can create and run ssis packages, when I try to do the same thing on server I get he following error right clicking on running packages or stored packages.
failed to retrieve data for this request. Library not Registered. (exception from HRESULT: 0x8002801D
there are 2 instances of SQL on this server. Both are named with one being use by SQLExpress and the other by SQL2005 Std
My home machine has sql 2005ÃÂ and Visual Studio 2005 installed. I uninstalled VS 2005 (RTM)ÃÂ and installed VS 2008 (RTM) in its place. I then found that the SSIS templates were missing. Lesson: don't uninstall VS 2005 if you want to use SSIS 2005!
1. Is there any "workaround" to this issue?
2. (If the answer to 1 is "No")ÃÂ I willÃÂ install VS 2008 side-by-side with VS 2005 on the same box.ÃÂ When the SSIS issue is finally resolved, can I uninstall VS 2005 without doing damage to theÃÂ VS 2008 install?