Export ASCII -x

Fri Nov 19 07:58:30 PST 2010

OK - that's all fine and dandy, *BUT*, after re-reading what Nancy had 
written below,
I now wonder if there is a difference between my fp 5.0.14 and whatever 
version she is using or maybe it could be *nix vs. windows for the 
results I got for putting r=\n after the -X (which didn't work in that 
order for me whereas it seems to have worked for her on her line 330 
shown below).

I can kind of see why (from an earlier post from Nancy):

So I tried adding it to myline
myxml(1)=myline{chr("13"){chr("10")

might not work if 'myline' took up the whole amount of space
(or maybe all but one char instead of two) allotted for the fixed output.

Bruce

Bruce Easton
STN, Inc.

On 11/19/10 10:36 AM, Bruce Easton wrote:
> Nancy, the usage of 'export ASCII.. -x' on fptech's site manual provides
> some good info on this (I used search there then 'EX' and then clicked
> on the first link '1'.)
>
> The -X option for export seems to only indicate that it is to make a
> fixed length file.  They also say there that files exported using -X
> will create files that can be immediately read by filepro.  Further they
> say that if you encounter problems reading such files (mapped from an
> alien-type map), to try to add a place (one for *nix, two for Windows i
> think) in the map to be reserved for the EOL char(s).  I would think
> then, if you use -X (without a r=\n), then you should not have to
> reserve a place in an alien file map meant to read the data from such an
> export, whereas if you do use the combo of -X and r=\n, then you do.
>
> But regardless of your purpose for the export, it does seem to require
> the 'r=\n' from my Linux box test to get a new line after the fixed
> length record (without trying to do something from the exported
> fields).  Also, it seems for my Linux and fp version 5.0.14 that you
> have to put the -x after the r=\n, otherwise the r=\n is ignored.
>
> Alternatively, from Linux and 5.0.14 fp again, I was able to export a
> file with newlines at end of each record by using only 'export ASCII
> ....  -X' and then in the processing (for a file with 3 fields):
>
> outf(1)=1
> outf(2)=2
> outf(3)=3
> outf(4)=chr("10")
>
> Similarly, I was able to do the same, but appending carriage returns
> before the newlines (pretending I was preparing the output file for some
> Windows use) with this processing:
>
> outf(1)=1
> outf(2)=2
> outf(3)=3
> outf(4)=chr("13")
> outf(5)=chr("10")
>
> I always get confused when I try first look at the output with vi after
> performing this latter test from Linux because I'm used to seeing the
> CR's as ^M on the line rather than the notation at the bottom of vi
> including '[dos]' and wondering if they are really there.  But I guess
> this is because I'm still also using vi a lot on SCO boxes.
>
> Bruce
>
>
> Bruce Easton
> STN, Inc.
>
>
>
>
>
>
>
> On 11/19/10 9:23 AM, Nancy Palmquist wrote:
>> Scott,
>>
>> Do you usually do a "Export ASCII file -x" or the more standard "Export
>> ACII file r=\n f=," version?
>>
>> It was the -x version that was supposed to provide the New Line and does
>> not have any field delimiter.  That is what it seemed to do but not when
>> I did not send at least one CR or LF.  When my data just was text it
>> provided no CR/LF ending.  That was my complaint.
>>
>> Nancy
>>
>> On 11/18/2010 4:21 PM, scooter6 at gmail.com wrote:
>>>    FWIW, I have always used  r=\n on ALL my imports and exports and have
>>> never had any issues like you describe
>>>     So my assumption would be it's always required?!?!  (but, I don't
>>> like to assume haha)
>>>    Scott
>>>
>>>
>>> On Thu, Nov 18, 2010 at 4:17 PM, Jeff Harrison
>>> <jeffaharrison at yahoo.com<mailto:jeffaharrison at yahoo.com>>   wrote:
>>>
>>>       ----- Original Message ----
>>>
>>>       >   From: Nancy Palmquist<nlp at vss3.com<mailto:nlp at vss3.com>>
>>>       >   To: filePro Mailing List<filepro-list at lists.celestial.com
>>>       <mailto:filepro-list at lists.celestial.com>>
>>>       >   Sent: Thu, November 18, 2010 2:04:14 PM
>>>       >   Subject: Export ASCII -x
>>>       >
>>>       [snip]
>>>
>>>       >   Well I finally found what it needed.  So I guess this  turned
>>>       out to be a
>>>       >   cautionary tale not a request for help after  all.
>>>       >
>>>       >   330  -------   -   -   -   -   -    -   -   -   -   -
>>>       >   wrtxml ? If:
>>>       >            Then: export ascii myxml=(expname{"") -x r=\n
>>>       >   331  -------    -   -   -   -   -   -   -   -   -    -
>>>       >           ? If:
>>>       >           Then:  myxml(1)=myline{chr("10") ;write myxml
>>>       >   332  -------   -    -   -   -   -   -   -   -   -    -
>>>       >
>>>       >   This caused my file to end up with CR/LF (0d 0a) just what was
>>>       >   required.  What weird logic is causing this but here it is if anyone
>>>       >   else is looking for a solution.
>>>       >
>>>       >   Nancy
>>>
>>>       Nancy, you still needed the chr("10") even after you added the
>>>       r=\n ?  I am not
>>>       able to test this at the moment, but I would think that this would
>>>       give you CR
>>>       then CR LF (oa od oa).  If it says that the record delimiter is a
>>>       new line by
>>>       default, then it sounds like the documentation should be updated
>>>       to reflect the
>>>       fact that you need to specify the r=\n to get the newline.
>>>
>>>       Jeff Harrison
>>>       jeffaharrison at yahoo.com<mailto:jeffaharrison at yahoo.com>
>>>
>>>
>>>
>>>       _______________________________________________
>>>       Filepro-list mailing list
>>>       Filepro-list at lists.celestial.com
>>>       <mailto:Filepro-list at lists.celestial.com>
>>>       Subscribe/Unsubscribe/Subscription Changes
>>>       http://mailman.celestial.com/mailman/listinfo/filepro-list
>>>
>>>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>