• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 752
  • Last Modified:

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

Open in new window

0
AviationAce
Asked:
AviationAce
  • 7
  • 6
1 Solution
 
Olaf DoschkeSoftware 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.
0
 
AviationAceAuthor 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.
0
 
Olaf DoschkeSoftware 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.
0
Restore individual SQL databases with ease

Veeam Explorer for Microsoft SQL Server delivers an easy-to-use, wizard-driven interface for restoring your databases from a backup. No expert SQL background required. Web interface provides a complete view of all available SQL databases to simplify the recovery of lost database

 
AviationAceAuthor 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.
0
 
tusharkanvindeCommented:
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.
0
 
Olaf DoschkeSoftware 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 = CREATEOBJECT("ADODB.Connection")
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()

Open in new window

0
 
Olaf DoschkeSoftware 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.
0
 
AviationAceAuthor Commented:
I get the day off today!  I will investigate this tomorrow.  Thanks for the insights.
0
 
AviationAceAuthor Commented:
Olaf;
The code you posted does not compile.  The compliler does not like the oConn.Open() or the oConn.Close() statements.
0
 
Olaf DoschkeSoftware DeveloperCommented:
perhaps this version?
dim oConn as object, oRS as object
 
oConn = CREATEOBJECT("ADODB.Connection")
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

Open in new window

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

Bye, Olaf.
0
 
AviationAceAuthor 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.
0
 
AviationAceAuthor 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.
0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

  • 7
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now