>>It's my guess that some means of explicit file locking of a Memo file must exist, looking at the stupids amongst us (I would be one of them ...) who are able to attach MemoFileX to DBFFileY (where it belongs to DBFFileX). How to do that ? not sure, but possibly there are some possibilities at explicitly opening a DBF in one directory, VFP finding the Memo (not in that directory) over the Set Path.
>
>The structure of the memo file and the corresponding field in the dbf is well explained in the documentation - there are ready reports with your installation of VFP which will print this stuff - and it's just plain close to impossible to do this sort of cuckoo egg substitution.
>
>The field in the DBF is just a number (N(10,0) in FPD and FPW, integer in VFP), which points to the ordinal number of the block within the FPT file (or absolute offset if you've Set Blocksize to 0). This number may change anytime you do something to a memo field. Even Copy To will change these numbers - because it copies only the used blocks, so they get renumbered (tried and tested - the effect is the same as in Pack Memo).
>
>So, to attach memos from one table to another table, you basically have to do it record-by-record, finding the block(s) of the x.fpt belonging to first record, extracting them as a string, saving it into the memo of y.dbf, then going to the next memo field/next record in table x, while not eof() (or feof(), depending on how are you doing it).
>
>I've done this - that's how my RebFpt utility works (downloadable here... I really should recompile it into VFP7), and it doesn't even try to do cuckoo-egg replacement, it rebuilds the whole .fpt memo by memo.


Dragan,

It needn't the explanation really, but thanks anyway.
For myself I compared it with Indices being the egg of a dbf-cuckoo. But of course, that "trick" is allowed more formally (Set Index To ...).

BTW, I never "learned" to use Memo's because the potential corruption is too scary. I heard that VFP7 is much better on this.

Thx,