# Importing an OLE object from VFP

I am porting a DB application from Visual FoxPro to MS Access 2007.  All the data has imported correctly with the exception of an embedded object.

In the old application (under Visual FoxPro) the user was given a "open file" dialog box where several .RTF files were listed.  The user would select an .RTF file and then it would be embedded in the DB as an object.

The problem is Access does not know what to do with this object.  If you look at the attached code you will see where I have tried a work around.  The text of the original .RTF file will display in MS Word, but it has around 30 random characters at the beginning.

Question: How do I tell Access to treat this embedded object as an MS Word object?
Private Sub part_number_DblClick(Cancel As Integer)
Open "E:\MyDir\OleOut.rtf" For Binary Access Write As #1
Put #1, , Me.doc_content.Value
Close #1
Call Shell("WinWord E:\MyDir\OleOut.rtf")
End Sub

###### Who is Participating?

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Software DeveloperCommented:
How was it embedded in the vfp database? In a field of type general? This would almost be a one way ticket with no easy way out. You'd need to do some binary extraction from the fpt file associated with the dbf.

But Maybe the rtf files are simply embedded as ascii in a memo field, no object. RTF files are rather simplistic text files with lots of curly braces for RTF "tags", almost like a markup language, there's no need to storeRTF as binary Blobs or general fields.

Bye, Olaf.
Sole-ProprietorAuthor Commented:
The field these .RTF files are stored in is not general or text.  They were stored as binary objects.  Embedded.  OLE.  I don't know why the humanoid that wrote the origianl program did it this way, but it is what I have inherited.
Software DeveloperCommented:
well, what is the field type in vfp, not what you see in access. Is it vfp9? then it could also be a blob or binary memo field. And I think a general field would also be seen as an binary object field in access. So it doesn't help to look at it from access, you need to know the dbf structure from the foxpro point of view.

Bye, Olaf.
Sole-ProprietorAuthor Commented:
The VFP application I'm working with is in runtime.  I don't have a copy of VFP to look at the DB structure.  All I know is what I see in Access.  I'm pretty sure it is an embedded OLE object in the VFP DB.  Even though all I am trying to extract are .RTF files, the application allows for any type of file to be embeded in the field in question.
Commented:
Feels like a general field to me. Which is normally a one way ticket even in VFP as Olaf said. Try removing the 30 odd characters until you get to { and then save the rest to a file.

Experts Exchange Solution brought to you by

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Software DeveloperCommented:
General field is the only field type for embedding ole object in vfp, but in access you see many fields as object fields which are not. You have the dbf at hand, then you can get the structure without havong the full version of vfp, install the oledb provider.

Then do this, after which you'll find structure infos about the dbf in the recordset oRS.
dim oConn as object, oRS as object

oConn.ConnectionString = "provider=vfpoledb.1;;data source=C:\path\to\dbf\"
oConn.Open()
oConn.Execute("execscript('use dbfname'+Chr(13)+'copy structure extended to structure')")
oConn.Close()
oConn.Open()
oRS = oConn.Execute("select * from structure')")
oConn.Close()

Software DeveloperCommented:
or instead of oRS = oConn.Execute("select * from structure')") simply import that structure.dbf to access like you did with the dbf itself.

Bye, Olaf.
Sole-ProprietorAuthor Commented:
I get the day off today!  I will investigate this tomorrow.  Thanks for the insights.
Sole-ProprietorAuthor Commented:
Olaf;
The code you posted does not compile.  The compliler does not like the oConn.Open() or the oConn.Close() statements.
Software DeveloperCommented:
perhaps this version?
dim oConn as object, oRS as object

oConn.ConnectionString = "provider=vfpoledb.1;;data source=C:\path\to\dbf\"
oConn.Open
oConn.Execute("execscript('use dbfname'+Chr(13)+'copy structure extended to structure')")
oConn.Close
oConn.Open
oRS = oConn.Execute("select * from structure")
oConn.Close

Software DeveloperCommented:
Andperhaps you first need to download and install the vfp oledb provider. Sorry if I assumed this is self-evident.

Bye, Olaf.
Software DeveloperCommented:
Sole-ProprietorAuthor Commented:
I already have that.  I needed it to import the old database in the first place.  I think I am getting close to a solution.  I have written some code to go through the data in this field byte by byte.  This is so un-elegant, but it seems to be getting the job done.  From what I can tell the contents of the files are stored in this field unaltered.  There is just some "junk" procedding it.
Sole-ProprietorAuthor Commented:
It looks like there was no easy way to solve this.  I got it done by analysing each field byte by byte.  I pain in the butt and not very elegant, but it got the job done.
###### It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.