| Author |
Topic |
|
slugfest
Starting Member
18 Posts |
 Posted - 2005-02-03 : 20:18:53
|
| Simple question...Does the built-in FTP Task USE ftp.exe to move files? If not, what? |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2005-02-03 : 20:31:55
|
| I don't believe it does, it's probably written completely internally to the DTS object model. FTP.EXE can also upload files, DTS FTP cannot. FTP.EXE is actually easier and more flexible to program than the DTS FTP task. Nigel has some examples on his site:http://www.nigelrivett.net/ |
 |
|
|
slugfest
Starting Member
18 Posts |
Posted - 2005-02-03 : 20:37:29
|
| Yeah, that's my problem. I have a client on a shared server. I set up a Execute Process Task to put files on another server, using ftp.exe, and the job failed. The tech tells me they don't allow non-sysadmins to run CmdExec jobs and that ftp.exe isn't even installed on the server. I was hoping that the FTP Task used ftp.exe so I could call him on it.Guess I'm out of luck. Thanks, Rob. |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2005-02-03 : 20:50:44
|
| Well, you might be able to run it as an Execute Process Task in a DTS package. Doubtful, but worth a shot. |
|
|
|
slugfest
Starting Member
18 Posts |
Posted - 2005-02-03 : 21:02:51
|
| That's how I had it set up, but no dice. Just another reason for me to set up a server here.Thanks, Rob. |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2005-02-03 : 21:07:00
|
Ahhhh crap.I could swear VBScript had a way to call executable files, but I'm probably thinking of VB's Shell function.Which, of course, you COULD write an ActiveX control in VB that calls shell to run the FTP.EXE utility... ...and you could call THAT from an ActiveX task...Have I impressed upon you my willingness to try even the craziest ideas yet?  On that note though, how about an ActiveX control that handles FTP? There are a few out there, and the standard WinInet controls can do it I think. |
|
|
|
slugfest
Starting Member
18 Posts |
Posted - 2005-02-03 : 21:14:44
|
| Hmm...don't know much about that approach. I will into it.Is this crazy...setting up a VBscript script on my local machine that pulls the data (off the remote server), drops the file and then FTPs it over. Is that doable locally? |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2005-02-03 : 21:19:48
|
| It should be possible. As for crazy, well, I've done crazier. Example: I was running a SQL 6.5 server and the SQL Executive (precursor to SQL Server Agent) wouldn't run on it. I got an eval copy of SQL Server 7.0 for my desktop computer and SQL Agent worked fine on it. I needed to backup the 6.5 databases regularly, so I created a SQL Agent job on my desktop that connected to the 6.5 server and ran the BACKUP command...using a DTS package by the way...Crazy isn't always a bad thing, as long as it gets the job done. |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2005-02-03 : 21:26:26
|
| Hang on for a Muppet News Flash from Damian, he has a much better way... |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2005-02-03 : 21:29:56
|
Actually, now I think about it, there is a much nicer way to do this.I used to have a job in a system that ran by shelling to ftp.exe. The problem is, you never have any way of finding out whether it worked properly or not. Also, sometimes the process hangs, and you end up with orphan ftp.exes running around... no fun.So, I solved this by grabbing this free FTP COM component, http://www.chilkatsoft.com/ChilkatFtp.asp and calling that from script.The very cool thing about this component is that you can write from memory, to a remote ftp file. So if you're pulling data from your DB, you don't need the step of writing the file locally and transferring it.Damian |
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2005-02-03 : 21:34:01
|
| Yea, shell can be a bit tempermental at times.Speaking of ftp components - we have been using this very nice, and stable, open source .net component:http://www.enterprisedt.com/products/edtftpnet/overview.htmlDamian, check it out, it offer a great feature set (ie active and passive mode, interupt resumption, custom event handling) |
|
|
|
slugfest
Starting Member
18 Posts |
Posted - 2005-02-03 : 21:34:35
|
| Thanks for the suggestions. I'll give them a whirl and get back to you tomorrow. |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2005-02-03 : 21:36:35
|
| How would you call a .Net component from a job or DTS package? Would it need a COM wrapper? |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2005-02-03 : 21:47:16
|
Jay, you rock  I had a look for a good .NET one a while back and didn't find anything. This looks great!Rob, yes, you can generate and register a COM wrapper.Damian |
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2005-02-03 : 22:05:23
|
| We really like it. It is well-designed, fast, and stable. Though we have mixed feelings regarding the logging funtionality they have incorporated into it. It is a very nice and functional logger - but we are quite fond of Log4Net http://logging.apache.org/log4net/ and kinda hate co-mingling other loggers. In fact one of our developers has been tasked with replacing the edtFTPnet logger logic with Log4Net's.Rob, lately we have been replacing our dts packages with .net codebase, in particular console apps. We feel it is a much richer environment (ie. much more robust framework, better error handling, controlling job flow, etc.) - In addition to the added functionality provided by the .net framework, our thought here is that once Yukon is released, the codebase can be easily ported to the appropriate layer(s) (ie back into the db via clr - or other options). |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2005-02-03 : 22:37:07
|
| I've not read much on this - Is Integration Services looking promising? Any good links to overviews? |
|
|
|
slugfest
Starting Member
18 Posts |
Posted - 2005-02-04 : 20:06:40
|
| Here was my solution. All performed on my local machine.1) Using Windows Scheduled Task, I created a VBS script and pulled records from the remote SQL server and wrote them to a CSV file.2) I then ran another scheduled task to FTP that CSV to another remote server.Works pretty well. |
|
|
|
|
FTP Task and FTP.exe