<what I submitted> Abstract: CPYFRMIMPF command . System Type: 9406 System Serial Number: 10-589ZM Operating System: i5/OS V5R3 Product Group: OS/400 - General, Other . Environment: V5R3, latest c-u-m, database, and hipers applied . Problem: Question regarding CPYFRMIMPF command when the data has an embedded " character. We receive files regularly from the State of Indiana in .csv format. Recently a file contained the following record: FDP,COM,"BP11","Freezer","72/5.5oz por.","15" Ital. Pizza","15" Italian Pizza",0,0,26,24.75,9.97,0,28,07/28/2004,| Note that there are 2 places in this record where the " (STRDLM character) appears within the data as opposed to being a string delimiter. When I use CPYFRMIMPF to get the date to a PF-DTA file, this is not handled properly. The data ends up fubar'ed from an application viewpoint. If I open the received .csv file with MS Excel, it is handled properly. I wouldn't want it to get out that MS has more intelligent software than IBM <g>. Seriously, I have no idea what the 'standards' say for such a situation. It could be that: 1) Excel should actually not open the file properly, MS is notorious for not following standards. 2) Or it could be that when the State of Indiana created the file, they should have doubled up the character so that the field read like this: "15"" Ital. Pizza". 3)Or it could be that CPYFRMIMPF should have looked at the next character and since it (the next character) wasn't a comma (the FLDDLM character), then the " should have not been treated as the STRDLM character. In any case, there needs to be some resolution. </what I submitted> <IBM Response> ________________________ 04/10/04-10:48--CR ____________________________ S7> COMPID= 5722SS100 Customer Rep: Jeffrey Action Taken: q to DB Action Plan: Rq to NETRSP with response-Thank you ________________________ 04/10/04-11:18--CT ____________________________ NO CONTACT IS REQUIRED ________________________ 04/10/04-11:59--CR ____________________________ S7> COMPID= 5722SS100 Customer: Jeffrey Problem: CPYFRMIMPF is not handling string delimiter " within string delimiters in a comma field delimited file. Action Taken: Investigate Action Plan: REQ to DBWK04 with Delay to investigate and respond. ________________________ 04/10/06-12:24--CR ____________________________ S7> COMPID= 5722SS100 Action Taken: Jeffrey - I investigated and contacted development and there currently is no support to handle a single string delimiter that is used within the same string delimiters. The processing fails because the code can attempt to find a 2nd matching string delimiter and therefore can go past the end of field delimiter, into the next field. I believe a circumvention for you would be to use a different string delimiter such as '~' or something other than a '"' which is being used as an inch symbol as well as string delimiter in your example. Unfortuneately the CPYFRMIMPF does not handle string delimiters within the same string delimiter as sometimes expected. The other option for you beyond the circumvention would be to submit a design change request so our development could consider a change for a future release. If you would like to this let me know and I can make sure you get a DCR form. I hope this is of help for you. Let know if I can close this PMR, or what you would like to do.... Thanks, Kevin. Action Plan: Await reponse from Jeffrey ________________________ 04/10/06-12:27--CC ____________________________ Customer Rep: Jeffrey Action Taken: Notified customer PMR has been updated Action Plan: Email-fup </IBM Response> <My response> It's the State of Indiana and they send this file to other businesses, not just us. They are not going to change the delimiter(s) due to this deficiency. I would like a DCR. </My response> -- Jeff Crosby Dilgard Frozen Foods, Inc. P.O. Box 13369 Ft. Wayne, IN 46868-3369 260-422-7531 The opinions expressed are my own and not necessarily the opinion of my company. Unless I say so.
This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact