>>The slack of a memo field is up to 64 bytes per record; the slack of a file in a directory rounds up to the next cluster size. The overhead of keeping track is 4 bytes per memo field in the .dbf and some 6 bytes in the .fpt field (per memo field&record); the overhead of keeping them in a disk file is the full or relative pathname you have to store somewhere in the .dbf, plus the name space for the directory structure.
>
>And how do you recommend recovering the image files WHEN the memo/general file gets corrupted? It is much better to store the image (once) as it is in a subdirectory with the relative path stored in the table.(IMNSHO)< G >

You can use my RebFpt utility :)

Kidding aside (I'm not kidding about the utility - it should work), memo fields are error prone in funky network conditions, and mostly while they are updated or added. As I have understood, your pictures will be more often read (hundreds of times) than written (once), so you shouldn't have trouble with that. And, since they're expected to pop up in no time, I assumed speed is more important. Never really liked usage of directory structure to do a table/index's job.

Well, this is just an opinion, or a personal preference, whatever. Maybe today's file system is faster than I'm used to, and slack isn't what it used to be.