Thanks again,
I do not think the user needs that much control.
It is more of a question of how much re-designing. We have tried splitting the dbf by date. But that gave us headaches, also.
I will suggest storing the path and name, and using Word Automation for editing. That will definitely keep the size way down.

<snip>
>Not really. I was giving you an alternative to linking or embedding. If you jst store the fullpath and document name in the memo field, that will be much less space taken up in the FPT. Linking to a document file should take less space in the memo field as opposed to storing the entire doc in the FPT.
>
>I am not sure of what your requirements are and how much control you need over the users opening and editing the Word documents. You can also split the table into multiple tables if the current system was working for you. Maybe use different tables to categorize the docs or otherwise organize the docs into proper tables.
>
>In the Word automation projects I have done, I store the Word doc in a regular memo field using the FileToStr() function. When the user starts the app, I recreate the DOC using the StrToFile() function, perform whatever automation on the doc, then ask the user to provide a filename to save the doc as. The original DOC is never altered ans is always available in original format in the memo field.
>
<snip>
>>>>Hi,
>>>>
>>>>I am new to linking and embedding Word Docs.
>>>>
>>>>We have one app that has embedded Word Docs and is running up against the 2 Gig limit.
>>>>We thought, use linking instead and keep the Word Docs in a special directory.
>>>>But, we have noticed that the FPT is still growing pretty quickly.
>>>>
>>>>When linking does FoxPro still keep copies of the Word Docs in the FPT?
>>>>
>>>>Any suggestions are appreciated,
>>>>Carol Dewar
>>>>Magram Computer Services