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.

>Thanks,
>So you are implying a "roll your own" for viewing and updating the Word Docs instead of using OLEControls?
>
>PACK MEMO means using the 2 Gig dbf Exculsively for a long time. That is another reason we are redesigning.
>
>Carol Dewar
>
>>Just keep a path and filename to the doc in the memo field. The actual doc is NOT stored in the FPT in this case.
>>
>>If you did not already, you can issue a PACK MEMO on the exclusively used table to reduce the bloat from when the actual docs were stored in the field.
>>
>>
>>>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