I strongly suggest to remove the binary length field from the file
before transferring the file to the SQL Server side.
The representation binary length 2 byte / char with fixed length is the
normal representation for DB2 VARCHAR columns that DB2 unload tools
like DSNTIAUL etc. generate. It is also the DB2 host variable format
for VARCHARs in COBOL programs etc.
But: when transferring DB2 VARCHAR data to a database like Oracle
or SQL Server (on another platform), you need a data exchange format,
that contains no binary fields.
For example, CSV, or flat textfiles with fixed offsets. Not binary files !!
You should be able to generate CSV directly from DB2 tables, if you
have the right tools.
<ad>
I am selling such a tool, call me offline for details.
My tool supports all the formats from above, and more.
The tool comes in different flavors, one for each database
(DB2, Oracle, SQL server), so it handles the communication on
both sides. Even flat textfile with fixed offsets is possible; in this
case,
there is no length information in the file, but trailing blanks for
varchars
are omitted (which is ok in most cases).
</ad>
Kind regards
Bernd
Am 15.04.2015 um 22:50 schrieb Ron Thomas:
ok still i am not able to know how in that flat file there is a length field,
how that is going to be interpeted in the SQL server side . the data is in
binary and when we unload to a txt file that part won't be readable. so do we
need to remove that field and send ? Thanks,
Ron T
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
