Is it even possible to read/write FoxPro tables from VB6 ??
It's hard to believe this has been so difficult. I admit to being from the
"old school" of programmers, so object models can stymie me for a bit. But
I have tried several mechanisms to open and then read and write to Visual
FoxPro tables from VB6 and, so far, nothing has worked.
I should first list my approach and my assumptions. If something has gone
awry, it is better to have it pointed out early than to have to deal with
it at the other end.
1) I have Visual Studio 6, which means both FoxPro and Visual Basic are version
6. I see that Visual Basic has no support for FoxPro tables beyond version
3. Are FoxPro version 6 tables sufficiently compatible that they may be
opened with version 3 references from Visual Basic 6?
2) In case there was an incompatibility, I’ve converted the FoxPro version
6 tables to version 3 format. I’ve seen no revealed capability to gain access
to these tables.
3) I see no mechanism for Visual Basic to grab onto a FoxPro “DBC” file and
become aware of all the tables within. Is it true that I must instead grab
each table, one by one? If so, I can still survive.
4) I understand that there can be three different schemes for getting hold
of a FoxPro table through Jet. I should be able to import it (I reject this
right away, as it is inappropriate to the task); I should be able to open
it; and I should be able to link to it. As this application is all taking
place on local machines with high bandwidth interconnection, I assume that
opening a table would be superior to linking to it. However, if I can get
either one working then I'll be satisfied. I have been focusing on opening
a file.
5) When linking or opening, when a field asks for the name of the database,
it is the fully qualified directory name which is given rather than the name
of a FoxPro DBC file, right?
6) I understand that ADO is the “modern” technique for interfacing with
FoxPro, and that DAO is now passé. I wouldn’t mind getting ADO working,
but after first experimenting with it I fell back to DAO. It may be more
nuts-and-boltsy, but it’ll be sufficient for now. Any solution is welcomed,
though.
7) Here’s one of the many sample codes which I was testing. I’ve selected
it because it is right out of a Microsoft book and it doesn’t work. I base
it upon a sample from “Microsoft Jet DataBase Engine Programmer’s Guide”,
page 330. This book comes with a CD, and upon that CD are sample FoxPro
tables. I note where I’ve modified the code or where I otherwise make comments.
Dim CurrentDatabase As Database
Dim MySet As Recordset
Dim tdf As TableDef
' Open the external FoxPro database.
' [note that this was not my comment, and it already throws
' me that it didn’t say “table”]
Set dbs=OpenDatabase("D:\JetBook\Samples\FoxTables\Sales", _
False, False, "FoxPro 3.0")
' [note that I copied the files from the CD to my local Drive
' D:, so the drive reference was changed accordingly.
' We are referring to their files, not mine]
' Return a reference to the FoxPro table.
Set tdf = dbs.TableDefs("EmpSales")
' Open a recordset on the table ...
Set rst = tdf.OpenRecordset
' [note that it is this last line which causes error]
Upon running, the request to open a recordset and to make an assignment to
rst causes the following error
Run-time error ‘13’:
Type mismatch
EmpSales.DBF appears to be a well behaved FoxPro table. I can open it in
FoxPro and I can browse it. It has two columns and less than a dozen records.
8) Is there some type of restriction as to the version of FoxPro table which
can be read by Visual Basic and written to, too? I sometimes come across
indistinct warnings that, under certain unspecified circumstances, Visual
Basic will not be able to write to a FoxPro table when version 3 tables are
used. Does this happen all the time? Does it happen at all? Is there a
workaround?
Visual Studio is sold as a lump, but when I try to get just two of its pieces
to work together it already shows roughness and sharp edges. I’ve been lacerated,
and I worry if there is more to come. Do you have any guidance at all?
Thank you,
Mel
Re: Is it even possible to read/write FoxPro tables from VB6 ??
Mel,
A TableDef in Microsloths own words. ' A TableDef object represents the stored
definition of a base table or a linked table (Microsoft Jet workspaces only).
'
Dim CurrentDatabase As Database ' should be defined as DAO.dbs :)
Dim MySet As Recordset ' should be defined as DAO.rst :)
Mel,
A TableDef in Microsloths own words. ' A TableDef object represents the stored
definition of a base table or a linked table (Microsoft Jet workspaces only).
'
Dim CurrentDatabase As Database ' should be defined as DAO.dbs :)
Dim MySet As Recordset ' should be defined as DAO.rst :)
Dim tdf As TableDef ' You dont need this
' Open the external FoxPro database.
Set dbs=OpenDatabase("D:\JetBook\Samples\FoxTables\Sales", False, False,
"FoxPro 3.0")
' Opens the table definition You dont need to do this unless you want to
modify the underlying table
' Set tdf = dbs.TableDefs("EmpSales")
' You cant open a record set from the table definition so this line is redundant
' Set rst = tdf.OpenRecordset
' This should do the trick
Set rst = dbs.OpenRecordset("EmpSales")
Cheers,
Kane
Re: Is it even possible to read/write FoxPro tables from VB6 ??
Mel
VB, through ADO, or Office peoducts through MSQuery or whatever have no
problem connecting to VFP DBCs or free tables through VFPODBC.
The latest version of VFPODBC is 6.1.8629.1
-Anders
"Mel Raab" <automagc@ix.netcom.com> wrote in message
news:38d66515$1@news.devx.com...
>
> It's hard to believe this has been so difficult. I admit to being from
the
> "old school" of programmers, so object models can stymie me for a bit.
But
> I have tried several mechanisms to open and then read and write to Visual
> FoxPro tables from VB6 and, so far, nothing has worked.
>
> I should first list my approach and my assumptions. If something has gone
> awry, it is better to have it pointed out early than to have to deal with
> it at the other end.
>
> 1) I have Visual Studio 6, which means both FoxPro and Visual Basic are
version
> 6. I see that Visual Basic has no support for FoxPro tables beyond
version
> 3. Are FoxPro version 6 tables sufficiently compatible that they may be
> opened with version 3 references from Visual Basic 6?
>
> 2) In case there was an incompatibility, I’ve converted the FoxPro version
> 6 tables to version 3 format. I’ve seen no revealed capability to gain
access
> to these tables.
>
> 3) I see no mechanism for Visual Basic to grab onto a FoxPro “DBC” file
and
> become aware of all the tables within. Is it true that I must instead
grab
> each table, one by one? If so, I can still survive.
>
> 4) I understand that there can be three different schemes for getting hold
> of a FoxPro table through Jet. I should be able to import it (I reject
this
> right away, as it is inappropriate to the task); I should be able to open
> it; and I should be able to link to it. As this application is all taking
> place on local machines with high bandwidth interconnection, I assume that
> opening a table would be superior to linking to it. However, if I can get
> either one working then I'll be satisfied. I have been focusing on
opening
> a file.
>
> 5) When linking or opening, when a field asks for the name of the
database,
> it is the fully qualified directory name which is given rather than the
name
> of a FoxPro DBC file, right?
>
> 6) I understand that ADO is the “modern” technique for interfacing with
> FoxPro, and that DAO is now passé. I wouldn’t mind getting ADO working,
> but after first experimenting with it I fell back to DAO. It may be more
> nuts-and-boltsy, but it’ll be sufficient for now. Any solution is
welcomed,
> though.
>
> 7) Here’s one of the many sample codes which I was testing. I’ve selected
> it because it is right out of a Microsoft book and it doesn’t work. I
base
> it upon a sample from “Microsoft Jet DataBase Engine Programmer’s Guide”,
> page 330. This book comes with a CD, and upon that CD are sample FoxPro
> tables. I note where I’ve modified the code or where I otherwise make
comments.
>
> Dim CurrentDatabase As Database
> Dim MySet As Recordset
> Dim tdf As TableDef
>
> ' Open the external FoxPro database.
> ' [note that this was not my comment, and it already throws
> ' me that it didn’t say “table”]
> Set dbs=OpenDatabase("D:\JetBook\Samples\FoxTables\Sales", _
> False, False, "FoxPro 3.0")
> ' [note that I copied the files from the CD to my local Drive
> ' D:, so the drive reference was changed accordingly.
> ' We are referring to their files, not mine]
> ' Return a reference to the FoxPro table.
> Set tdf = dbs.TableDefs("EmpSales")
> ' Open a recordset on the table ...
> Set rst = tdf.OpenRecordset
> ' [note that it is this last line which causes error]
>
> Upon running, the request to open a recordset and to make an assignment to
> rst causes the following error
>
> Run-time error ‘13’:
> Type mismatch
>
> EmpSales.DBF appears to be a well behaved FoxPro table. I can open it in
> FoxPro and I can browse it. It has two columns and less than a dozen
records.
>
> 8) Is there some type of restriction as to the version of FoxPro table
which
> can be read by Visual Basic and written to, too? I sometimes come across
> indistinct warnings that, under certain unspecified circumstances, Visual
> Basic will not be able to write to a FoxPro table when version 3 tables
are
> used. Does this happen all the time? Does it happen at all? Is there a
> workaround?
>
>
> Visual Studio is sold as a lump, but when I try to get just two of its
pieces
> to work together it already shows roughness and sharp edges. I’ve been
lacerated,
> and I worry if there is more to come. Do you have any guidance at all?
>
> Thank you,
> Mel
>
Re: Is it even possible to read/write FoxPro tables from VB6 ??
If you have both DAO and ADO references set, you should use ADODB.Recordset,
etc.
What it sounds like is that you're trying to assign one type of object to
another type of object, such as ADODB.Recordset to DAO.Recordset
On the other hand, I haven't actually tried this, so it's just a guess on
my part.
Roger
">> 7) Here’s one of the many sample codes which I was testing. I’ve selected
>> it because it is right out of a Microsoft book and it doesn’t work. I
>base
>> it upon a sample from “Microsoft Jet DataBase Engine Programmer’s Guide”,
>> page 330. This book comes with a CD, and upon that CD are sample FoxPro
>> tables. I note where I’ve modified the code or where I otherwise make
>comments.
>>
>> Dim CurrentDatabase As Database
>> Dim MySet As Recordset
>> Dim tdf As TableDef
>>
>> ' Open the external FoxPro database.
>> ' [note that this was not my comment, and it already throws
>> ' me that it didn’t say “table”]
>> Set dbs=OpenDatabase("D:\JetBook\Samples\FoxTables\Sales", _
>> False, False, "FoxPro 3.0")
>> ' [note that I copied the files from the CD to my local Drive
>> ' D:, so the drive reference was changed accordingly.
>> ' We are referring to their files, not mine]
>> ' Return a reference to the FoxPro table.
>> Set tdf = dbs.TableDefs("EmpSales")
>> ' Open a recordset on the table ...
>> Set rst = tdf.OpenRecordset
>> ' [note that it is this last line which causes error]
>>
>> Upon running, the request to open a recordset and to make an assignment
to
>> rst causes the following error
>>
>> Run-time error ‘13’:
>> Type mismatch
>>
>> EmpSales.DBF appears to be a well behaved FoxPro table. I can open it
in
>> FoxPro and I can browse it. It has two columns and less than a dozen
>records.
>>
>> 8) Is there some type of restriction as to the version of FoxPro table
>which
>> can be read by Visual Basic and written to, too? I sometimes come across
>> indistinct warnings that, under certain unspecified circumstances, Visual
>> Basic will not be able to write to a FoxPro table when version 3 tables
>are
>> used. Does this happen all the time? Does it happen at all? Is there
a
>> workaround?
>>
>>
>> Visual Studio is sold as a lump, but when I try to get just two of its
>pieces
>> to work together it already shows roughness and sharp edges. I’ve been
>lacerated,
>> and I worry if there is more to come. Do you have any guidance at all?
>>
>> Thank you,
>> Mel
>>
>
>
Re: Is it even possible to read/write FoxPro tables from VB6 ??
I am having the same problem. There is no problem connecting to the Visual
Foxpro table using ADO. The problem I have is with updating records in the
table. My project does not require adding records so I am not sure if this
works or not.
"Anders Altberg" <anders.altberg@swipnet.se> wrote:
>Mel
>VB, through ADO, or Office peoducts through MSQuery or whatever have no
>problem connecting to VFP DBCs or free tables through VFPODBC.
>The latest version of VFPODBC is 6.1.8629.1
>
>-Anders
>
>"Mel Raab" <automagc@ix.netcom.com> wrote in message
>news:38d66515$1@news.devx.com...
>>
>> It's hard to believe this has been so difficult. I admit to being from
>the
>> "old school" of programmers, so object models can stymie me for a bit.
>But
>> I have tried several mechanisms to open and then read and write to Visual
>> FoxPro tables from VB6 and, so far, nothing has worked.
>>
>> I should first list my approach and my assumptions. If something has
gone
>> awry, it is better to have it pointed out early than to have to deal with
>> it at the other end.
>>
>> 1) I have Visual Studio 6, which means both FoxPro and Visual Basic are
>version
>> 6. I see that Visual Basic has no support for FoxPro tables beyond
>version
>> 3. Are FoxPro version 6 tables sufficiently compatible that they may
be
>> opened with version 3 references from Visual Basic 6?
>>
>> 2) In case there was an incompatibility, I’ve converted the FoxPro version
>> 6 tables to version 3 format. I’ve seen no revealed capability to gain
>access
>> to these tables.
>>
>> 3) I see no mechanism for Visual Basic to grab onto a FoxPro “DBC” file
>and
>> become aware of all the tables within. Is it true that I must instead
>grab
>> each table, one by one? If so, I can still survive.
>>
>> 4) I understand that there can be three different schemes for getting
hold
>> of a FoxPro table through Jet. I should be able to import it (I reject
>this
>> right away, as it is inappropriate to the task); I should be able to open
>> it; and I should be able to link to it. As this application is all taking
>> place on local machines with high bandwidth interconnection, I assume
that
>> opening a table would be superior to linking to it. However, if I can
get
>> either one working then I'll be satisfied. I have been focusing on
>opening
>> a file.
>>
>> 5) When linking or opening, when a field asks for the name of the
>database,
>> it is the fully qualified directory name which is given rather than the
>name
>> of a FoxPro DBC file, right?
>>
>> 6) I understand that ADO is the “modern” technique for interfacing with
>> FoxPro, and that DAO is now passé. I wouldn’t mind getting ADO working,
>> but after first experimenting with it I fell back to DAO. It may be more
>> nuts-and-boltsy, but it’ll be sufficient for now. Any solution is
>welcomed,
>> though.
>>
>> 7) Here’s one of the many sample codes which I was testing. I’ve selected
>> it because it is right out of a Microsoft book and it doesn’t work. I
>base
>> it upon a sample from “Microsoft Jet DataBase Engine Programmer’s Guide”,
>> page 330. This book comes with a CD, and upon that CD are sample FoxPro
>> tables. I note where I’ve modified the code or where I otherwise make
>comments.
>>
>> Dim CurrentDatabase As Database
>> Dim MySet As Recordset
>> Dim tdf As TableDef
>>
>> ' Open the external FoxPro database.
>> ' [note that this was not my comment, and it already throws
>> ' me that it didn’t say “table”]
>> Set dbs=OpenDatabase("D:\JetBook\Samples\FoxTables\Sales", _
>> False, False, "FoxPro 3.0")
>> ' [note that I copied the files from the CD to my local Drive
>> ' D:, so the drive reference was changed accordingly.
>> ' We are referring to their files, not mine]
>> ' Return a reference to the FoxPro table.
>> Set tdf = dbs.TableDefs("EmpSales")
>> ' Open a recordset on the table ...
>> Set rst = tdf.OpenRecordset
>> ' [note that it is this last line which causes error]
>>
>> Upon running, the request to open a recordset and to make an assignment
to
>> rst causes the following error
>>
>> Run-time error ‘13’:
>> Type mismatch
>>
>> EmpSales.DBF appears to be a well behaved FoxPro table. I can open it
in
>> FoxPro and I can browse it. It has two columns and less than a dozen
>records.
>>
>> 8) Is there some type of restriction as to the version of FoxPro table
>which
>> can be read by Visual Basic and written to, too? I sometimes come across
>> indistinct warnings that, under certain unspecified circumstances, Visual
>> Basic will not be able to write to a FoxPro table when version 3 tables
>are
>> used. Does this happen all the time? Does it happen at all? Is there
a
>> workaround?
>>
>>
>> Visual Studio is sold as a lump, but when I try to get just two of its
>pieces
>> to work together it already shows roughness and sharp edges. I’ve been
>lacerated,
>> and I worry if there is more to come. Do you have any guidance at all?
>>
>> Thank you,
>> Mel
>>
>
>
Re: Is it even possible to read/write FoxPro tables from VB6 ??
Try creating an ODBC DSN then using ADO to retrieve the data.
"Alan Howard" <ahoward@huntron.com> wrote:
>
>I am having the same problem. There is no problem connecting to the Visual
>Foxpro table using ADO. The problem I have is with updating records in the
>table. My project does not require adding records so I am not sure if this
>works or not.
>
>"Anders Altberg" <anders.altberg@swipnet.se> wrote:
>>Mel
>>VB, through ADO, or Office peoducts through MSQuery or whatever have no
>>problem connecting to VFP DBCs or free tables through VFPODBC.
>>The latest version of VFPODBC is 6.1.8629.1
>>
>>-Anders
>>
>>"Mel Raab" <automagc@ix.netcom.com> wrote in message
>>news:38d66515$1@news.devx.com...
>>>
>>> It's hard to believe this has been so difficult. I admit to being from
>>the
>>> "old school" of programmers, so object models can stymie me for a bit.
>>But
>>> I have tried several mechanisms to open and then read and write to Visual
>>> FoxPro tables from VB6 and, so far, nothing has worked.
>>>
>>> I should first list my approach and my assumptions. If something has
>gone
>>> awry, it is better to have it pointed out early than to have to deal
with
>>> it at the other end.
>>>
>>> 1) I have Visual Studio 6, which means both FoxPro and Visual Basic are
>>version
>>> 6. I see that Visual Basic has no support for FoxPro tables beyond
>>version
>>> 3. Are FoxPro version 6 tables sufficiently compatible that they may
>be
>>> opened with version 3 references from Visual Basic 6?
>>>
>>> 2) In case there was an incompatibility, I’ve converted the FoxPro version
>>> 6 tables to version 3 format. I’ve seen no revealed capability to gain
>>access
>>> to these tables.
>>>
>>> 3) I see no mechanism for Visual Basic to grab onto a FoxPro “DBC” file
>>and
>>> become aware of all the tables within. Is it true that I must instead
>>grab
>>> each table, one by one? If so, I can still survive.
>>>
>>> 4) I understand that there can be three different schemes for getting
>hold
>>> of a FoxPro table through Jet. I should be able to import it (I reject
>>this
>>> right away, as it is inappropriate to the task); I should be able to
open
>>> it; and I should be able to link to it. As this application is all taking
>>> place on local machines with high bandwidth interconnection, I assume
>that
>>> opening a table would be superior to linking to it. However, if I can
>get
>>> either one working then I'll be satisfied. I have been focusing on
>>opening
>>> a file.
>>>
>>> 5) When linking or opening, when a field asks for the name of the
>>database,
>>> it is the fully qualified directory name which is given rather than the
>>name
>>> of a FoxPro DBC file, right?
>>>
>>> 6) I understand that ADO is the “modern” technique for interfacing with
>>> FoxPro, and that DAO is now passé. I wouldn’t mind getting ADO working,
>>> but after first experimenting with it I fell back to DAO. It may be
more
>>> nuts-and-boltsy, but it’ll be sufficient for now. Any solution is
>>welcomed,
>>> though.
>>>
>>> 7) Here’s one of the many sample codes which I was testing. I’ve selected
>>> it because it is right out of a Microsoft book and it doesn’t work.
I
>>base
>>> it upon a sample from “Microsoft Jet DataBase Engine Programmer’s Guide”,
>>> page 330. This book comes with a CD, and upon that CD are sample FoxPro
>>> tables. I note where I’ve modified the code or where I otherwise make
>>comments.
>>>
>>> Dim CurrentDatabase As Database
>>> Dim MySet As Recordset
>>> Dim tdf As TableDef
>>>
>>> ' Open the external FoxPro database.
>>> ' [note that this was not my comment, and it already throws
>>> ' me that it didn’t say “table”]
>>> Set dbs=OpenDatabase("D:\JetBook\Samples\FoxTables\Sales", _
>>> False, False, "FoxPro 3.0")
>>> ' [note that I copied the files from the CD to my local Drive
>>> ' D:, so the drive reference was changed accordingly.
>>> ' We are referring to their files, not mine]
>>> ' Return a reference to the FoxPro table.
>>> Set tdf = dbs.TableDefs("EmpSales")
>>> ' Open a recordset on the table ...
>>> Set rst = tdf.OpenRecordset
>>> ' [note that it is this last line which causes error]
>>>
>>> Upon running, the request to open a recordset and to make an assignment
>to
>>> rst causes the following error
>>>
>>> Run-time error ‘13’:
>>> Type mismatch
>>>
>>> EmpSales.DBF appears to be a well behaved FoxPro table. I can open it
>in
>>> FoxPro and I can browse it. It has two columns and less than a dozen
>>records.
>>>
>>> 8) Is there some type of restriction as to the version of FoxPro table
>>which
>>> can be read by Visual Basic and written to, too? I sometimes come across
>>> indistinct warnings that, under certain unspecified circumstances, Visual
>>> Basic will not be able to write to a FoxPro table when version 3 tables
>>are
>>> used. Does this happen all the time? Does it happen at all? Is there
>a
>>> workaround?
>>>
>>>
>>> Visual Studio is sold as a lump, but when I try to get just two of its
>>pieces
>>> to work together it already shows roughness and sharp edges. I’ve been
>>lacerated,
>>> and I worry if there is more to come. Do you have any guidance at all?
>>>
>>> Thank you,
>>> Mel
>>>
>>
>>
>