>>In order to communicate with Sterling Commerce EDI products I need to create a flat file that contains multiple record types. In COBOL I did this with a master record then an infinite number of REDEFINEs for that record for each record type. How does one do this in VFP?
>>
>>Regards/yb
>
>
>Maybe I'm missing something here, but wouldn't
>
>COPY TO (filename) TYPE SDF
>
>work?
I am not familiar with Sterling EDI, but I do know COBOL. I think the problem you are facing is one of converting a relational database ( your source data is VFP, right? ) to a targe flat file that can be processed by the classic mainframe non-self-defining files. The important points to remember is that when dealing with mainframe files like this are: 1) the fields are all fixed length, with no delimiters for fields or records, just data data data data. In the past, the critical factors of RecordLength and BlockSize governed the physical recording of the data. ( NOTE: variable length record support is a subtle variation on this theme with a binary count of the number of bytes ( usually a 32 bit interger ] preceeding each record, but still with a group of fixed length fields strung out following this length. To impliment the variable lenght record, the COBOL environment division statement linking the data division file to the OS's JCL / Command Language needed to specify this feature, so check to see if you need to do this ). The reference to an "infinite" number of redefines following the first record was probably multiple '01' level's redefining each other in the data division -- right? If you are still with me, we are getting close to Foxpro's way to create these files. Most of these 'COBOL' files will have their matching key defined in a common grouping -- very ofter the first 'nnn' bytes of the record, which facilitates sorting, and matching to other 'COBOL' files with identical matching key fields. ( I am being a little sloppy in the use of the term 'field' since in COBOL any string, beginnning anywhere, for any length may be termed a 'field' unlike the self-defining file field definitions in Foxpro. Anyway, lets say that you are sending out invoices generated by the 'Mom & Pop' store to 'Mega Monster Customer' for E.D.I. ( I would hope that Sterling follows one of the two main standards for record formats -- either the ANSI X12 set of E.D.I. document standards, or the Electronic Data Interchange Association: UCS Retail Applications -- because once you code up a set of these routines, you can use them again with other customers, at least here in the U.S.A. ) Back to the data: You will need to make available all the tables you need, in use simultaneously -- how you knit them together is up to you, Views are nice ( avoid the wizard ), or hard-code your own relations with 'SET ORDER TO', 'SET FILTER' and having the record layouts for the 'COBOL' files in front of you, code a main 'SCAN / ENDSCAN' for the controlling file ( let's assume invoice header ), and then code the building of each record, with embedded 'looping' where detail records are involved. Thus you might have a set of coding that looks like:

select 0
use Customer
select 0
use InvoiceHdr
select 0
use InvoiceDtl
do visiual form GetRange && ask user for range of invoice numbers
if .not. lGoodResponse && some kind of test for validity of continuing
quit && might want to display a message just prior to this
endif
nCobolFile = Fcreate (.......)
select InvoiceHdr
set order to tag InvoiceNo
scan for InvoiceNo => nInvoiceLow .and. InvoiceNo =< nInvoiceHigh
*
* Build header record from data in Customer and Invoicehdr
*
FWrite(...)
*
* Scan through the detail lines for the invoice
*
Scan
FWrite(...) && this doesn't have to look like the header record
EndScan
Select InvoiceHdr
EndScan
FClose(...)
*
* might be nice to show some counts here...
*
That's all I have time for -- if I misspelled anything, sorry, this is not from a real program, but parallels some I have done to talk to 'COBOL' systems.