Re: Uploading CSV and/or numeric data

> I have a program which dumps a comma-delimited text file and I'm
> attempting to get it onto the 400 and into a PF.  I've successfully
> tested creating a file on the 400, downloading that file, and using that
> FDF to upload data in the same layout.

If you have done so successfully, then what problem are you still trying
to solve?   Do you dislike this method?

> I know you can specify that your data to upload is comma delimited but
> when I do that I get a message saying the FDF hasn't been specified.

When you did the download, and let it auto-create the FDF for you, why not
save that FDF and re-use it?   It seems to me that this is the easiest way
to make an FDF...  let the system create one for you during a download,
even if it's just a "dummy" download, and then re-use it for the
uploads...

> So I set about to put the data into a format that would be easy to
> upload.  I suck the CSV into Access and use a query to append the data
> to a table that has custom formats of "000000.0000" which will force the
> fields into the correct lengths, thus creating "fixed width" fields.
> But exporting the data loses the leading zeros and the decimals aren't
> aligned.  I've tried upload numeric fields where the decimals aren't
> aligned and the 400 puked on the non-aligned decimals.  So I try
> exporting the data as text and get the non-aligned decimals.  Then I
> notice the "Save Formatted" checkbox which offers me the choice of
> saving in Windows, MSDOS, Unicode, or Unicode UTF8.  I try all 4 and
> while I now get decimal alinged fields, I also get a line of dashes
> (--------) between each line of data.  I could write a VB program to
> strip out the lines with dashes.

I don't really understand why any of this is necessary...?   Instead of
writing a VB program, why not write an RPG program that reads the file
from the IFS directly (the same way that your VB program would've done it)
and then writes the resulting data straight to your PF?


> In a subsequent test I notice that one of the formats I can export the
> data in is ODBC.  So I select this, attach to the 400, and the file
> auto-magically appears on the 400.  But when I look at the data, the
> first 3 or 4 fields (which are text) look fine but the rest (which are
> numeric) are gibberish.  Not hex - I know hex - this is gibberish.
> Characters I've only seen on "The Matrix".

That's an interesting statement.   I know the Matrix part is a joke.  Is
the "Not hex - I know hex" part a joke?!  Because it does not make sense
to me.

> Is there something really easy I'm missing about:
> 1)  uploading a CSV file to the 400,

Make a PF to receive it.  put a dummy record in the PF.   Download the PF
from the AS/400 to the PC, telling CA to output as a CSV on the PC.  Tell
it to create/save the FDF.

Now clear the file and use the FDF to do the upload.   You say above that
this works for you, then didn't explain why you aren't simply using it?

> 2)  dumping the data out of Access in fixed width fields,

Seems unnecessary.

> 3)  sending numeric data via ODBC?

I don't do ODBC.

>
> And yes, I know if I were on V5R1 this would all be a lot easier.
>

Aside from the CPYFRMIMPF command (which, for me, always comes close to
working, but never totally works) I don't see where this would buy you
anything.   I did a lot of CSV import in V3R2, I simply wrote RPG programs
that read the stream files.   Sure, it's more work (the first time) than
using CA, but there I have total control of how the data is parsed.

I didn't find using CA upload/download to be very difficult, though.  and
that hasn't really changed since V3R2.