Yes I do with an OLEBound control on a modal form which I call with the controlsource as a parameter. And there is an Edit button, yes. I was asked to do it that way; the client was a bit afraid of an edit-on-demand structure.

>I see. Do you actually display the contents of the word docs on your form? How does the user go into "edit" mode? If the user has to click a button to go into edit mode, I believe you could still use the idea of getting the general field only at this stage.
>
>>Hi Daniel,
>>
>>A problem with that idea is that it'll break the UI. See, the user thinks that when a new document is created, that the clauses are created too, just empty. And this is essentially true with all of the General fields in the document table because I go through the General fields when the record is created and APPEND GENERAL a template Word document.
>>
>>So if I had a separate edit/create for the clauses, it would confuse them...they think the document is already created, albeit empty.
>>
>>
>>>I'm not sure how the user inteface looks. Maybe one option would be to define a view that doesn't contain the general fields but an indication of whether the field contains a document or not. Someting like this:
>>>
>>>

>>>SELECT keyField,;
>>>       IIF(EMPTY(General1), .f., .t.) AS lHasDoc1,;
>>>       IIF(EMPTY(General2), .f., .t.) AS lHasDoc2,;
>>> etc...
>>>

>>>
>>>You could then display a < Show/Edit/Delete > button for fields that contain a document and a < Create > button if there's no document. When the user clicks the button, you go and get the actual document. You could use the approach suggested by Larry to force the user to save or cancel all the changes or alternatively decide to change the data from the modal form.
>>>
>>>Hope I'm not off the topic here :)
>>>
>>>>Hi Folks,
>>>>
>>>>I have an application that's a secure document management system. Each document is composed of contract clauses, each of which is stored in a General field. Each client can have multiple documents.
>>>>
>>>>This application evolved over time and the document child table now has about a dozen General fields. The document table is represented in the main application screen by a view (for simplicity, I'll call it lvdocuments). Lvdocuments is optimistic table buffered and in the application it's requeried if the user clicks on a list of documents for the current client and when the client is changed. The client table is a table and is optimistic row buffered.
>>>>
>>>>The client is concerned about the speed of the application. It's a bit more sluggish as time goes on. I have been considering moving each document clause (read: General field) into a grandchild table, but my main question is this:
>>>>
>>>>Will the general application speed increase or decrease by remiving all of the General fields from the documents table and putting them in child tables? Each table is much more lightweight, but then I have a dozen more views to requery...and then there's the issue of updating and reverting if the user changes the current document while editing.....
>>>>
>>>>This is the only application I maintain that uses a slew of General fields and I'm thinking the answer is not so obvious....
>>>>
>>>>Opinions and ideas are welcome!