|
> 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.
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.