>>>Fox2x dbf doesn't use that positions at all (12-31 reserved). But I don't think it as feasible. You would at least need exclusive access to be able to write there. <<
>
>I understand this. We build these tables from EBCDIC or ASCII files and then the file is passed thru several people and many processes are run on it, but only one person has the file at a given time.
>
>>>There are plenty of spaces that you could write this info. Even a dummy file or another table. <<
>
>Of course was is my first thought, and my plan B. But the nature of what they do requires them to move the tables around. Another file would be easy to loose and tracking it in a database without some kind of unique id would be problematic. Files from different states may be in different directories with the same file name.
>
>>> There are changes in header from FP2x to VFP and no one knows if those positions would be free forever. <<
>
>This is a good point.
>
>>>OTOH if it has a memo file than memo header has much more unused space. But in that case too you should guarantee that operations like SQL copy and delete old, modi stru etc wouldn't be done at all.<<
>
>This is potential problem even using the DBF header. If anyone copies the file or modifies structure, my key is lost and linking it up again could really be a problem. I need to determine which is more likely, loosing a separate file or losing my little key in the header.
>
>Thanks Cetin

---

If security is not a much concern here then including another field (ie: 5 chars holding a checksum) might be an easy option (but as I understand it's not:)
Cetin