"I have no expectation that the FTP would know what to do if there were NULL
values"
FWIW, null field values appear to be supported courtesy of the FTP
subcommand NULLFLDS (recommended for inter-system-i FTP only). Never tried
it myself.
More info available here (V6R1):
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzaiq/rzaiqnul
lflds.htm
Richard
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: 24 October 2012 15:16
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Unable to FTP an SQL table containing LOBs between two System I
servers.
But the scenario describes a homogeneous request; i.e. only IBM i systems
involved. There reasonably should be little reason the client and server
could not handle BLOB data just as it would be able to handle other data
types; e.g. BINARY, DATE, PACKED, etc. Why would there be any difference,
between the way the described scenario should handle transport of the data
for the two examples shown here, each a TABLE with the same row of data?:
create table qtemp/ABLOB (c char, b blob (200)) ;
create table qtemp/ABINARY (c char, b binary(200)) ;
insert into qtemp/ABLOB values
('1', cast('text as *binary* data' as binary(200)) ) ;
insert into qtemp/ABINARY values
('1', cast('text as *binary* data' as binary(200)) ) ;
Though I asked the question, I have no expectation nor hope that the FTP
would handle either "properly", just as I have no expectation that the FTP
would know what to do if there were NULL values. That is because the FTP is
*not* a generic database data transport mechanism. I am merely alluding to
the potential for consistency; that, as a binary stream, the data could be
handled consistently for both sending and receiving, of both examples. I
would even expect that the CPYF utility using FMTOPT(*CVTSRC) or
FMTOPT(*NOCHK) could enable copying the data as well, consistently for each
TABLE above. However the BLOB data appears as the string '*POINTER' instead
of the inserted data; I understand the design and the effect as implemented,
though again [like with the FTP], the effect could be handled consistently
for the Copy File data requests of the two files.
--
Regards, Chuck
On 24 Oct 2012 03:51, Tim Bronski wrote:
It's not just the iSeries ftp. If you think about it you can see the
issue: how would this table (blob included) be represented in a binary
stream (which is all an FTP connection is). FTP doesn't define any
structure on the data - it's up to the client and server to interpret
the data as best they see fit. In a binary stream how would you as a
receiver pick out the blob portion of the record or even know what a
record was?
On 10/24/2012 12:44 AM, Troy Hyde wrote:
I have recently been approached by someone in my shop about their
inability to transfer (using FTP) SQL tables that contain LOB rows
(BLOB in this case).
We receive error 426-Unable to open or create target file Followed by
426 Data transfer ended It appears to me that there may be an
inability with the OS/400 FTP to transfer tables containing LOBs but
I have been unable to verify it.
Can anyone confirm or deny the ability and perhaps instruct me why it
might not work if it is in fact allowed.
We are running V6R1 on both servers and the table exists on both
servers. It is empty on the target (server) system. I am in binary
stream mode.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
