header records on an export file

Brian K. White brian at aljex.com
Tue Sep 21 15:28:23 PDT 2004


Jeff Harrison wrote:
> --- Rick Mitchell <fpuser at mitchbg.com> wrote:
>
>> I have modified my system:
>>
>> It does the count, get's the filename and opens the
>> export record header
>> subroutine
>>
>> export day1=(fd) R=^j f=\,
>>
>> day(1)="IA", etc.
>>
>> Close day1
>>
>> Then as it processes calls another subroutine
>>
>> export day=(fd) r=^j f:\, -a
>> return
>>
>> then the export works
>>
>> day(1)="IL";day(2)="FEBCO"
>> day(3)=2; day(3)=4; day(5)=5
>>
>> etc.
>>
>> When I close both records after writing, i get
>> failures and it dumps out of
>> processing after trying to write the first data
>> record.
>>
>> if i close only the header i get error on first data
>> record.  I press F ad
>> it goes on and writes the file correctly.   Maybe i
>> need a delay before
>> reopening the file for append?
>>
>>
>
> I think the problem is that you have two different
> "export" statements in your processing.  I don't think
> that is allowed.

It's allowed, I'm doing it.


>  Try making it one statement and do
> your assignments in subroutines - one subroutine for
> the header and one for the detail.  You will need to
> use export ascii with the -a flag, so you'll probably
> want to initialize your file at the beginning of this
> process with a separate command - jsfile would be a
> pretty simple way to do this.

The problem was not just making a header line that comes before the first 
data line and is not itself a data line,
The problem was that the header line needs to be a different number of 
fields from the following data loines and fp is providing trailing empty 
fields on the first line which he can't have.
One export command won't work unless he changes the export to use only one 
big field, which I happen to hate doing unless there is really no other way.
Yes it gives you more control, which is perfect when you need it.
But it also throws away some work that filepro is sitting there ready to do 
for you, and I find using alias(n) = aa far easier to read and quicker to 
modify than z = "\"" { aa { "\",\"" { bb { "\",\"" {.....
or the hardly better  q="\",\"" ; z = "\"" { aa { q { bb { q  { ... { "\""
appending one value at a time helps but still kinda blows compared to using 
the alias
q = "\",\""
z = "\"" { aa { q
z = z { bb { q
z = z { cc { q
z = z { ... { "\""
If you are going to build the entire line byte by byte yourself, you might 
as well use file-io commands and/or basic instead of fp.

Also I just realised....
I think actually fp _will not_ create those empty fields even with only one 
export command, so long as you simply haven't referenced them yet.
ie: don't say csv(17)="" and it won't create empty fields from 4 to 17
at least not on the first record where field 17 has never been mentioned 
yet.
I could have sworn I had to go out of my way on some csv export to get the 
full number of fields on every line even if there was an unbroken trail of 
empties at the end of some lines
I think what it is is the lines won't ever shrink, but they can start out 
short and get longer on succeeding records.
That just happens to be the pattern he wants, and I've already done it with 
two export commands anyways, but I wonder if two export comands will let you 
make shorter lines that come after longer lines?

I'm testing for these questions now...

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani



More information about the Filepro-list mailing list