ctl.Action = acOLECreateLink giving Error 2785

  • Thread starter Thread starter fly girl
  • Start date Start date
F

fly girl

I have an MS Access app that uses an ole container control
to allow the user to view linked files. However, when I
try to attach files to this control I am getting a strange
error: "OLE Server wasn't able to open the object".

Here's the code:

With Me!oleLinked
.Enabled = True
.Locked = False
.OLETypeAllowed = acOLELinked
.SourceDoc = strFilePath
.Action = acOLECreateLink
End With

This seemed bulletproof when I tested it in a MS Access
project file but now that I have folded it into the actual
app with an .mdb front end I get the following result:

The first time I try to run this code, it fails with the
error 2785. The second time I run it for the exact same
file, it works just fine.

Detail:

User selects file to link. Note: the control's Ole Type
Allowed property is set to "Linked" so they must choose an
existing file and it is linked to the control.

When the user moves off the control the
control_AfterUpdate code runs in which I do several things.

1) I identify the file that the user linked by parsing the
header from the database.
2) I make a copy of the user's file and place it into my
controlled directory with a record-specific name, I'll
call it 'File A'.
3) I verify that File A is there. (At this time I can go
to the directory and open the file just fine--and, of
course I close it before proceeding with the code.)
4) If File A is where I want it, I delete the link in the
control to the user's file and establish a link to File A.

Step 4 is where the code blows up. However, the exact same
file (but with a different name) was just successfully
opened by the OLE Server! GRRRR!

If I manually delete the user's file and then run the
exact same steps again, IT WORKS! The only difference
seems to be that File A exists in the controlled directory
prior to running the code in the second round and didn't
the first time.

Has anyone divined the mysteries of what is going on with
error 2785?

Thanks!
 
Note also that if, prior to linking the file, I go out to
the directory holding 'File A' and open and close the
file, then the file will be linked as expected with no
error!

What the @#$$ is going on here?
 
Hi,

According to the article 311147, we can try to remove the current object
before setting the new path and file name to SourceDoc;

objform.Recordset.Edit
objform.Recordset(objform(OLEName).ControlSource) = ""
objform.Recordset.Update

ACC2000: How to Programmatically Change the Paths to Linked OLE Objects
http://support.microsoft.com/?id=311147

Please feel free to reply to the threads if you have any concerns or
questions.



Sincerely,

Alick Ye, MCSD
Product Support Services
Microsoft Corporation
Get Secure! - <www.microsoft.com/security>

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
| Content-Class: urn:content-classes:message
| From: "fly girl" <[email protected]>
| X-Tomcat-NG: microsoft.public.access.formscoding
|
| I have an MS Access app that uses an ole container control
| to allow the user to view linked files. However, when I
| try to attach files to this control I am getting a strange
| error: "OLE Server wasn't able to open the object".
|
| Here's the code:
|
| With Me!oleLinked
| .Enabled = True
| .Locked = False
| .OLETypeAllowed = acOLELinked
| .SourceDoc = strFilePath
| .Action = acOLECreateLink
| End With
|
| This seemed bulletproof when I tested it in a MS Access
| project file but now that I have folded it into the actual
| app with an .mdb front end I get the following result:
|
| The first time I try to run this code, it fails with the
| error 2785. The second time I run it for the exact same
| file, it works just fine.
|
| Detail:
|
| User selects file to link. Note: the control's Ole Type
| Allowed property is set to "Linked" so they must choose an
| existing file and it is linked to the control.
|
| When the user moves off the control the
| control_AfterUpdate code runs in which I do several things.
|
| 1) I identify the file that the user linked by parsing the
| header from the database.
| 2) I make a copy of the user's file and place it into my
| controlled directory with a record-specific name, I'll
| call it 'File A'.
| 3) I verify that File A is there. (At this time I can go
| to the directory and open the file just fine--and, of
| course I close it before proceeding with the code.)
| 4) If File A is where I want it, I delete the link in the
| control to the user's file and establish a link to File A.
|
| Step 4 is where the code blows up. However, the exact same
| file (but with a different name) was just successfully
| opened by the OLE Server! GRRRR!
|
| If I manually delete the user's file and then run the
| exact same steps again, IT WORKS! The only difference
| seems to be that File A exists in the controlled directory
| prior to running the code in the second round and didn't
| the first time.
|
| Has anyone divined the mysteries of what is going on with
| error 2785?
|
| Thanks!
|
 
Thanks for your response Alick.

However, this was not the problem. I was already doing
that but by a much more simple method when in the module
of an Access form:

Me.oleContainerControl = ""

I am happy to report that I just discovered the solution
to my problem. For some reason I don't understand, in
an .mdb file you must also clear out the "SourceDoc" for
the control prior to linking the new file.

This was not necessary in a .adp file.

Again thanks for trying to help and if you can, you might
put something up about this on the Knowledge Base. I did
find one other post of someone reporting this exact same
problem so I'm not the only poor programmer who is trying
to divine the differences between .mdb and .adp.

Gail Schipper
 
Hi Gail,

Thank you for sharing the resolution with us, I believe this will benefit
everyone in the newsgroup. I will inform the right person so that perhaps
they can update the article soon.

Please feel free to reply to the threads if you have any concerns or
question.




Sincerely,

Alick Ye, MCSD
Product Support Services
Microsoft Corporation
Get Secure! - <www.microsoft.com/security>

This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------
| Content-Class: urn:content-classes:message
| From: "fly girl" <[email protected]>
|
| Thanks for your response Alick.
|
| However, this was not the problem. I was already doing
| that but by a much more simple method when in the module
| of an Access form:
|
| Me.oleContainerControl = ""
|
| I am happy to report that I just discovered the solution
| to my problem. For some reason I don't understand, in
| an .mdb file you must also clear out the "SourceDoc" for
| the control prior to linking the new file.
|
| This was not necessary in a .adp file.
|
| Again thanks for trying to help and if you can, you might
| put something up about this on the Knowledge Base. I did
| find one other post of someone reporting this exact same
| problem so I'm not the only poor programmer who is trying
| to divine the differences between .mdb and .adp.
|
| Gail Schipper
| >-----Original Message-----
| >Hi,
| >
| >According to the article 311147, we can try to remove the
| current object
| >before setting the new path and file name to SourceDoc;
| >
| > objform.Recordset.Edit
| > objform.Recordset(objform(OLEName).ControlSource)
| = ""
| > objform.Recordset.Update
| >
| >ACC2000: How to Programmatically Change the Paths to
| Linked OLE Objects
| >http://support.microsoft.com/?id=311147
| >
| >Please feel free to reply to the threads if you have any
| concerns or
| >questions.
| >
| >
| >
| >Sincerely,
| >
| >Alick Ye, MCSD
| >Product Support Services
| >Microsoft Corporation
| >Get Secure! - <www.microsoft.com/security>
| >
| >This posting is provided "AS IS" with no warranties, and
| confers no rights.
| >
| >--------------------
| >| Content-Class: urn:content-classes:message
| >| From: "fly girl" <[email protected]>
| >| X-Tomcat-NG: microsoft.public.access.formscoding
| >|
| >| I have an MS Access app that uses an ole container
| control
| >| to allow the user to view linked files. However, when I
| >| try to attach files to this control I am getting a
| strange
| >| error: "OLE Server wasn't able to open the object".
| >|
| >| Here's the code:
| >|
| >| With Me!oleLinked
| >| .Enabled = True
| >| .Locked = False
| >| .OLETypeAllowed = acOLELinked
| >| .SourceDoc = strFilePath
| >| .Action = acOLECreateLink
| >| End With
| >|
| >| This seemed bulletproof when I tested it in a MS Access
| >| project file but now that I have folded it into the
| actual
| >| app with an .mdb front end I get the following result:
| >|
| >| The first time I try to run this code, it fails with
| the
| >| error 2785. The second time I run it for the exact same
| >| file, it works just fine.
| >|
| >| Detail:
| >|
| >| User selects file to link. Note: the control's Ole Type
| >| Allowed property is set to "Linked" so they must choose
| an
| >| existing file and it is linked to the control.
| >|
| >| When the user moves off the control the
| >| control_AfterUpdate code runs in which I do several
| things.
| >|
| >| 1) I identify the file that the user linked by parsing
| the
| >| header from the database.
| >| 2) I make a copy of the user's file and place it into
| my
| >| controlled directory with a record-specific name, I'll
| >| call it 'File A'.
| >| 3) I verify that File A is there. (At this time I can
| go
| >| to the directory and open the file just fine--and, of
| >| course I close it before proceeding with the code.)
| >| 4) If File A is where I want it, I delete the link in
| the
| >| control to the user's file and establish a link to File
| A.
| >|
| >| Step 4 is where the code blows up. However, the exact
| same
| >| file (but with a different name) was just successfully
| >| opened by the OLE Server! GRRRR!
| >|
| >| If I manually delete the user's file and then run the
| >| exact same steps again, IT WORKS! The only difference
| >| seems to be that File A exists in the controlled
| directory
| >| prior to running the code in the second round and
| didn't
| >| the first time.
| >|
| >| Has anyone divined the mysteries of what is going on
| with
| >| error 2785?
| >|
| >| Thanks!
| >|
| >
| >.
| >
|
 
OK, well my 'fix' worked until about 3:00 today. Then I
went back to the original error and problem.

I did try setting the field to Null in the database but
that didn't help either. If I do that, since the user is
actually in the field I've set to Null that causes all
kinds of other problem.

It would be so nice if the application could at least
perform or error consistently!

Fly girl
 
Hi,

What happens if you perform the following:

1- Create a simple *.bmp file in the "Controlled Directory" and name it
"Test.bmp"

2- Create an Unbound Object Frame in a blank new Form and call it
"OLEUnboundTest"

3- Create the following code behind this new Form and run it via a command
button

Function TestLink()

With Me!OLEUnboundTest
.Enabled = True
.Locked = False
.OLETypeAllowed = acOLELinked
.SourceDoc = "c:\Controlled Directory\Test.bmp"
.Action = acOLECreateLink
End With

FileCopy "c:\Controlled Directory\Test.bmp", "c:\Controlled
Directory\Test2.bmp"

With Me!OLEUnboundTest
.Enabled = True
.Locked = False
.OLETypeAllowed = acOLELinked
.SourceDoc = "c:\Controlled Directory\Test2.bmp"
.Action = acOLECreateLink
End With

Kill "c:\Controlled Directory\test.bmp"

End Function

Does it work?

Thanks,

Eric Butts, MCSE, MCDBA
Product Support Services
Microsoft Corporation
Get Secure! - <www.microsoft.com/security>

This posting is provided "AS IS" with no warranties, and confers no rights.
 
In an act of desperation I placed the necessary controls
on a new form in my project and ran the same code against
the new form. It worked perfectly.

Can I assume the old form somehow became corrupted? Can I
hope that the new form will not?

Thanks!
G
-----Original Message-----
Hi,

What happens if you perform the following:

1- Create a simple *.bmp file in the "Controlled Directory" and name it
"Test.bmp"

2- Create an Unbound Object Frame in a blank new Form and call it
"OLEUnboundTest"

3- Create the following code behind this new Form and run it via a command
button

Function TestLink()

With Me!OLEUnboundTest
.Enabled = True
.Locked = False
.OLETypeAllowed = acOLELinked
.SourceDoc = "c:\Controlled Directory\Test.bmp"
.Action = acOLECreateLink
End With

FileCopy "c:\Controlled
Click to expand...
Directory\Test.bmp", "c:\Controlled
 
fly said:
In an act of desperation I placed the necessary controls
on a new form in my project and ran the same code against
the new form. It worked perfectly.

Can I assume the old form somehow became corrupted? Can I
hope that the new form will not?
Click to expand...

There's always hope!

Sorry, but I couldn't resist ;-)

I think your assumption about corruption is probably
correct.
 
Back
Top