The following code is designed to open an embedded word file. Apparently the VERB and ACTION properties cannot be accessed.

Private Sub Command6_Click()
Rem opens Readme Table
Dim cdbs As DAO.Database
Dim crst As DAO.Recordset

Set cdbs = CurrentDb
Set crst = cdbs.OpenRecordset("readme", dbOpenDynaset)
Set Me.Recordset = crst

crst.MoveFirst
crst.FindFirst "keyid='hist'"
Rem Debug.Print "Key = "; crst!keyid
Rem Debug.Print crst!documentid

Me.documentid.Verb = acOLEVerbOpen <=Error Message generated here
Me.documentid.Action = acOLEActivate <=Error Message generated here
End Sub

I have been getting the error message "method or data not found". When I type in the string "me.documentid.", I only get the option of "value". However, when I go to another database, that also has an embedded word document, I get both the VERB and ACTION options. Also when I double click on the field directly, Word opens as expected. I suspect that one of my references may be missing. Attached is a copy of my refrences.

Of Course the problem still could be something else.

PS: Looks like I have another problem, my image upload didn't work from what I can tell???

Have you checked to see if the references are the same in the two db's?
<ALT> F11 then Tools>References...
You could also have a bogus MISSING reference causing you problems.
http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

Well, I ran three tests and they all failed. I imported the table that worked on the other database and it wouldn't work. I created a whole new test database from scratch and that didn't work. I also attempted to create a new table in the database where the VERB and ACTION properties worked, but they didn't take. I suspect the VERB and ACTION properties work as a residual operation since the other database was developed at work and now that it has been imported to my home computer, I can't add new stuff. I will check the references when I get to work tommorrow.

1) what is documentid out of interest
2) does access offer you the verb and action methods from a drop down list

if not, there is probably something wrong with the way you are using documentid

Gemma:
1. Documentid is the field that holds the MS WORD document. The "easy" solution would be to make this a MEMO field, but then I would still have this unresolved "flaw" with ACCESS. The purpose of the table is to provide "readme" stuff to the user.

2. When I use the access database that I created at work, as opposed to the one created at home, I do get the dropdown list provided that I am using a form. On the home developed access database, I don't.

I brought my home database to work. I am at work now, as time allows, I will test it out at work.

Does anyone know, which reference file would hold the ACTION and VERB properties? The best bet may be simply to re-register the reference file.

do you still have the work (working copy) - check the references in there.

most likely candidate is ms-word oblect library

No luck, I'm going to have to hang it up for a while.

1. I added the word object library, but that didn't work.
2. I created a new form that access the same table on the database where the existing form works as expected. The new form doesn't work. I get the message that the VERB and ACTION properties cannot be found eventhough they can be found by the existing form.
3. I checked the references (work and home versions of access) and they match.
4. As a side note, when I create a new database at work, I get the same failure, no dropdown for VERB and ACTION. That leads me to suspect that I did something on my work database that allows these properties to be used. I have been tracing the code, but can't find anything. Well back to work.

Figured it out. On the form that does work, I have the OLE field embedded in the form as a control. The control is set to NOTvisible and it is somewhat obscured by other controls. Also the control has the same name as the OLE field in the table that it belongs to. Consequently, when I created the new form and added the VBA code for the command button's onclick event, I mistook it as a direct reference to the table, not the OLE control on the form. Groan.

Outstanding! Thanks for posting back with your success. Another good reason for adopting a good naming convention for objects.

Ecellent Point. I have screwed myself many times with ambigous names and even the unintential use of a reserved word. Slowly, I am learning.

Been there...Done that! Take care. ;)