>>it a try. If there's a way you may capture a page or two of some ASCII
>>report done from the file, and include it with the file (.zip or .arj,
>>please), it'd be some help as to control the resulting table. It may
>>consist of fields like num1, num2 etc, since we know nothing of the
>>original structure, so the field names can be only imaginary.
>>
>>If it works, you get the source you can run against the big table - if
>>possible, send me a smaller sample, say - a few hundred records. My
>>phone line is a mess, so I try to minimize online time.
>>
>>ndragan@sezampro.yu
>
>As I mentioned before, I heve very little information off these files.
>There are different reports availble; but all with different layout and
>different data. I have talked with my client and he told me not to bother :
>his secretary will retyp this file (and the extra info that now is availble
>in my project.
>So you don't have to do anything anymore for this case.
>But when I have an other client with COBOL files, I will contact you.
>Thanks for your time !
I'll be around. For anyone else interested in this kind of thing, the
pattern is the same: I need a sample of the table with a few dozen
records (never mind if it's chopped off) just to find out the layout of
the data. Having the description from the Data Division helps a little
(you get familiar field names) but I have never (literally never) got an
updated one: every time the actual structure differs from what's in the
table. The urge for documenting the software probably originates from
the necessity to tame the cobol programmers (me too - I've worked three
years in it).
What I make in the end is a Fox routine (VFP or FPD -never mind, no OOP
stuff inside) which creates a table of appropriate structure, reads the
original file low-level, chops it into records and fields, and converts
the field values into proper fox values, then stores them into records
of the .dbf, and so on until feof(), one routine per original table
structure.