Re: Uploading CSV and/or numeric data

The file I've downloaded is a fixed length record, standard, plain vanilla
PF.  I checked and I don't see an option to download a file as CSV.  Again,
could be a function of using an old version of CA.


----- Original Message -----
From: "Scott Klement" <klemscot@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, July 01, 2003 5:39 PM
Subject: 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.
> _______________________________________________
> 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.
>