Hi!

I specially agree with 1) and that is what I meant - provide a TP program created that .DAT file.

3) might be not enough. Analizing of data require also to know the logical purpose of each data field, that is not such an easy thing.

>>Hi!
>>
>>I worked a lot with Turbo Pascal, but do not remember any DAT files. Maybe you have some unusual tools developed for Turbo Pascal? Then it is not a part of Turbo Pascal, tell what these tools. I can take a look to it and help you if you have Turbo Pascal program created these .DAT files.
>>
>>>Does anybody know how to access a Turbo Pascal "dat" file from VFP6.0
>>>Any help will be greatly appreciated ...
>
>It could be using some leftover format of relative files which existed in Turbo Pascal 2.0 or so - I vaguely remember some specs for the CP/M version of it - and, in general, the format would be deemed weird nowadays. It had a two-byte length at the beginning of a record, numbers were stored as they were in memory (short LSB integers, 4-byte floats etc), and the strings as well - probably fixed length with actual length in the leading byte or so.
>
>Generally, whenever anyone asks for .dat files of any source, my advice is to
>1) find the source of the code which created them
>2) since the source will be obsolete (won't match the actual structure), try to get a fresher one or proceed to 3)
>3) look at the hex dump of the file and try to figure the structure out yourself.
>
>The reason for this pessimistic approach is the historical fact that pretty much anyone who came up with a proprietary format (and I've seen really weird ones) gave it a .dat extension. That extension was rather common on cupboards (aka big iron), and there were no other sources of data files, most of the software was homemade, by either in-house staff or the iron manufacturer. When some of these things got ported to PCs (including TP, various dialects of Basic and many brands of Cobol), the habit of naming the data files .dat has survived.