January 13, 2014 at 7:09 pm
Your powers of observation are quite strong despite the look of your profile pic ;).
I was commenting on the old post about the need to troubleshoot and debut packages remotely justifying RDP access which was in this thread.
January 13, 2014 at 10:03 pm
ducon (1/13/2014)
Your powers of observation are quite strong despite the look of your profile pic ;).I was commenting on the old post about the need to troubleshoot and debut packages remotely justifying RDP access which was in this thread.
You have commented on an off-topic part of a four-year-old thread - without quoting the post you were referencing. Time to stop digging sir 😀
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
March 24, 2019 at 3:25 am
I guess there is still a bit of a bitter taste.
It's one thing, to require installing SSIS, when you need the service, to back up your package execution.
And it's somewhat a different thing, when you need to just execute package from some machine. Yeah, it does imply, somewhat, that somewhere this package needs to talk to SQL Server.
But, if this package needs, for example,
1. to access an remote network share to ingest some files
2. you don't have power of DBA / sa account over SQL Server itself and installing Agent Jobs is a ridiculous pain, to such a point, that it's not considered as a viable production deployment option
3. and somewhere, along the way, package talks to Microsoft SQL Server , of course, licensed and all, Enterprise edition, 2017.
not having an option of deploying dtexec.exe on some machine, to invoke SSIS package from Windows Scheduler really hamstrings you.
All in all, these aren't services, but client tools. Circa 2000 Microsoft was somewhat tepid, with regards to allowing to deploy Microsoft SQL Server tools away, from the machine running Microsoft SQL Server daemon service. Than sqlpackage.exe, bcp.exe, sqlcmd.exe, other tools, libraries became available in, what is now all know as "Feature Pack". It would be nice if dtexec.exe follows the suit. Not, that I have strong opinion. Yeah, I can package functionality into EXE, if that's what you ask. But I just happened to like SSIS and I don't see why policy should be precluding from running SSIS based applications from command line, without paying for additional SQL Server license ( as long as one is accurately and correctly procured, for instance, running on some machine )
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply