>Well, I knew what needed to be done before I posted the message but am still unclear as to what tools are at my disposal. I am not a network administrator and therefore don't know what options exist for securing these documents and templates at the directory/network level. Most privileges I am aware of are based upon the user's login or a group memebership and therefore, would be in effect for the entire time the user is logged in. I would think it to be impossible to both grant access from within the application and restrict it from outside using a directory-level approach. Naomi provided a link to an external utility that allows one to change directory priviledges from within the application. This might work but does it also prevent external access while the app is running? (I haven't tested it yet because I'm not sure that is the solution.)
>
>Also, I am not aware of a way for VFP to regain control of Word after the user is done editing but before the user is allowed to save the document. That would seem to be critical to insuring that the copy of the document is saved in the user's personal directory. These are the primary pieces of information I'd hoped to find here on UT.
>
>I have wondered if the documents and templates could be stored within the application or in a table but there's much more to them than just text. The documents have elaborate formatting (that's why each has its own .dot file) and most contain sophisticated graphics. I can't envision storing them as other than a .doc file and expecting them to 'reconstitute' properly--but perhaps I'm just lacking in imagination :-) When I attempted to store large, complex data in a table a few years ago the table became enormous and was easily corrupted. Perhaps that is less of a problem now? So I'll ask: iIs it possible and practical to store Word documents and templates within a VFP or SQL table? If so, what is the best way to do it?

Two ways cross my mind, both involving binary (i.e. nocptran) memos; one would be one file at a time (with full relative path stored in another field), and the other would be to zip the whole structure (.doc, .dot, graphic) together into the same record, then unpack as needed. Or keep the doc/dot pair in one record, and a common set of auxiliary files in a parent record, perhaps.

The key to trimming your table's size is to do a regular Pack Memo - which you can always do while table is in your hands, in development, and need not do at all in production, as the table would be read only there.