>>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.