|
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. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.