Archived Forum Post

Index of archived forum posts

Question:

Download Binary Data ftp to image field in sql

Jul 31 '13 at 14:08

Can I Download Binary Data through ftp to image field in sql ?

something like this? (this doesn´t work)

DECLARE @tmp TABLE (Datos image)
INSERT INTO @tmp EXEC sp_OAMethod @ftp, 'GetRemoteFileBinaryData',null ,@FILENAME

When running I get:

ChilkatLog: GetRemoteFileBinaryData: DllDate: Nov 23 2010 UnlockPrefix: XXXXXXFTP Username: Sxxxxxn Component: ActiveX ModeZ: 0 BinaryMode: 1 Passive transfer mode hostAddr: 127.0.0.1 DataConnect: hostname: 127.0.0.1 port: 60698 ConnectTimeoutMs: 60000 myIP: 127.0.0.1 myPort: 60699 connect successful. PassiveDataConnectionSetupTimeMs: Elapsed time: 0 millisec RetrFilename: [TestFile.pdf] RETR_reply: 150 Connection accepted DownloadRate: 0 NumBytesReceived: 34850 ReceiveTimeMs: Elapsed time: 0 millisec Data connection closed. statusCode3: 226 finalReply: 226 Transfer OK ReadFinalReplyTimeMs: Elapsed time: 0 millisec

But table @tmp is empty

THANKS IN ADVANCE !!!!


Answer

If using an old version of Chilkat, such as the case here ("DllDate: Nov 23 2010") then the answer is always to first test with the latest version. If the problem remains, then you can continue investigating -- but use the latest version because the information in the LastErrorText is potentially better.

If the LastErrorText indicates success, and it shows that binary data should've been returned, then the problem is likely in one of two places:

1) The problem is located in the Chilkat ActiveX COM layer (the layer that is internal to Chilkat, but external to the actual inner C++ implementation). When Chilkat is used in different environments (COM, .NET, Objective-C, etc.) the internal C++ implementation is identical. What changes is the outermost layer that transitions from the inner C++ class to the exposed API.

or

2) The problem is located in the SQL server code. Maybe the Chilkat ActiveX is behaving properly, but it has something to do with the SQL or the amount of data returned. Unfortunately, I don't work with SQL enough to know.

One way to help diagnose the location of the problem is to test the same code in a different environment. For example, test in a VB6, VBScript, or something else where GetRemoteFileBinaryData is called and the data is saved to a file. If it works in a different environment, then it shows that the ActiveX must be correctly returning the data and the source of the problem is external to the ActiveX itself.


Answer

Updated DLL To most recent. Still empty table @tmp

Response:

ChilkatLog: GetRemoteFileBinaryData: DllDate: Jul 10 2013 ChilkatVersion: 9.4.1.26 UnlockPrefix: XXXXXFTP Username: XXXXXXXXX Architecture: Little Endian; 64-bit Language: ActiveX / x64 VerboseLogging: 0 ProgressMonitoring: enabled: yes heartbeatMs: 0 sendBufferSize: 65536 --ProgressMonitoring AutoGetSizeForProgress: 0 GetFileToOutput_2: getFileToOutput2_1: ModeZ: 0 BinaryMode: 1 Passive transfer mode setupPassiveDataSocket2: hostAddr: 127.0.0.1 DataConnect: hostname: 127.0.0.1 port: 52962 ConnectTimeoutMs_1: 60000 calling ConnectSocket2 IPV6 enabled connect with NO heartbeat. This is an IPV4 numeric address... AddrInfoList: AddrInfo: ai_flags: 4 ai_family: 2 ai_socktype: 1 ai_protocol: 0 ai_addrlen: 16 ai_canonname: (NULL) --AddrInfo --AddrInfoList Connect using IPV4. ipAddress1: 127.0.0.1 myIP_3: 127.0.0.1 myPort_3: 52963 connect successful (2) socketOptions: SO_SNDBUF: 8192 SO_RCVBUF: 8192 TCP_NODELAY: 0 --socketOptions --DataConnect --setupPassiveDataSocket2 PassiveDataConnectionSetupTimeMs: Elapsed time: 0 millisec RetrFilename: [TestFile.pdf] RETR_reply: 150 Connection accepted downloadRate: 0 totalNumBytesReceived: 34850 receiveTimeMs: Elapsed time: 0 millisec Data connection closed. statusCode3: 226 finalReply: 226 Transfer OK ReadFinalReplyTimeMs: Elapsed time: 0 millisec --getFileToOutput2_1 --GetFileToOutput_2 --GetRemoteFileBinaryData --ChilkatLog


Answer

1) Please post LastErrorText's within <pre> and </pre> tags to maintain line endings.

2) The LastErrorText indicates success. Now follow through with the remainder of the debugging I described...