Using VFP with FOX2X tables

Discussion:

(too old to reply)

Jeff Grippe

2010-08-18 14:17:35 UTC

Hi Everyone, Thanks for the help.

I've found a tool that I'd like to use that will only operate on DBF's
in FOX2X format. I do not use DBC's. If I convert my tables to FOX2X,
other than losing some new data types like DateTime and Integer, will
there be any performance issues? Are tables in FOX2X format any slower
to access than the newer VFP format or are the differences mainly to
support new types, DBC, long field names, etc.?

Put another way, If I don't use DBC's and have no plans to, is there
any reason not to convert my data to FOX2X?

Thanks again,
Jeff

Dan Freeman

2010-08-18 14:50:11 UTC

Permalink

Post by Jeff Grippe
Hi Everyone, Thanks for the help.
I've found a tool that I'd like to use that will only operate on DBF's
in FOX2X format. I do not use DBC's. If I convert my tables to FOX2X,
other than losing some new data types like DateTime and Integer, will
there be any performance issues? Are tables in FOX2X format any slower
to access than the newer VFP format or are the differences mainly to
support new types, DBC, long field names, etc.?
Put another way, If I don't use DBC's and have no plans to, is there
any reason not to convert my data to FOX2X?
Thanks again,
Jeff

There's no speed difference at all.

The only problem you're likely to encounter is one of convenience. Some
operations will inadvertently flip the identity bit back to VFP. But if
you're vigilant you can code around that.

Dan

Jeff Grippe

2010-08-18 15:56:02 UTC

Permalink

Post by Dan Freeman

There's no speed difference at all.
The only problem you're likely to encounter is one of convenience. Some
operations will inadvertently flip the identity bit back to VFP. But if
you're vigilant you can code around that.
Dan

Thanks Dan.

Do you know what some of the pitfalls are?

I'm guessing that if I create a maintenance routine that does
something like:

USE <table>
COPY TO TEMP FOX2X
&& Blow Away Table
USE TEMP
COPY TO <table> FOX2X
&& rebuild all indexs

Then I could make sure that they stay in 2X format.

Thanks for the help.

Dan Freeman

2010-08-18 16:13:18 UTC

Permalink

Post by Jeff Grippe

Post by Dan Freeman

There's no speed difference at all.
The only problem you're likely to encounter is one of convenience. Some
operations will inadvertently flip the identity bit back to VFP. But if
you're vigilant you can code around that.
Dan

Thanks Dan.
Do you know what some of the pitfalls are?
I'm guessing that if I create a maintenance routine that does
USE <table>
COPY TO TEMP FOX2X
&& Blow Away Table
USE TEMP
COPY TO <table> FOX2X
&& rebuild all indexs
Then I could make sure that they stay in 2X format.
Thanks for the help.

Been a while since I've had to deal with it so I don't remember all of
the operations that can cause problems, but a pack & reindex routine
that ends with COPY FOX2X should allow users to always set things
right.

Dan

Lew

2010-08-20 12:49:13 UTC

Permalink

Column names greater than 10 chars will be truncated back to the 10
char fox2x max. This may cause problems with indexes that have the
greater than 10 char col names written into their key expressions.

Dan Freeman

2010-08-20 14:22:59 UTC

Permalink

Post by Lew
Column names greater than 10 chars will be truncated back to the 10
char fox2x max. This may cause problems with indexes that have the
greater than 10 char col names written into their key expressions.

But he's not using DBCs so long field names won't be in the mix.

Dan

Jeff Grippe

2010-08-20 15:39:51 UTC

Permalink

Hi Everyone, I got this reply and wrote the following on the Google
group. If anyone has anything else to add to this or about ADO
specifically, I'd like to know.

Thanks again

Thanks for the reply.
We do use memo fields but there isn't a great deal of code that deals
with them. I some important places we do have indexes on EMPTY(<MEMO
FIELD>) so that we can quickly extract records with memos (a
minority)
Also from what I remember (and my memory isn't what it used to be),
we
were using indexes on DELETED() to speed up queries even back in the
Fox2x DOS days.
The other product that I'm going to use apparently stopped at FOX2X
format because after that, the format when proprietary (or they
didn't
want to do the work to change their product). They can access VFP 9
data using ADO connections and that actually could work. I haven't
decided which way to go.
I assume that using ADO for my queries give me access to rushmore and
doesn't leave me a the mercy of how well they've implemented query
optimization.
For now, I'm only looking at queries to fetch data to feed a web
site.
Even if I decide to use this tool for the parts of my web site that
actually take in data, I can have the data entered into a temporary
table and then have my FoxWeb applications stick it into the DBF's
using real VFP.
If I decide to write desktop applications with this software then I
will need to decide what to do with my data.
If you know anything about ADO that you can share, please do. I've
never worked with it before.
Thanks again.
On Aug 19, 3:03 am, tg <***@googlemail.com> wrote:

- Hide quoted text -

"Suffer" might be a bit harsh... If you curently do not use the speed
benefits of the newer datatypes the step back will mostly be from
having memo pointers 10bit wide in Fox2X to 4 bit in vfp. Should not
be a dramatic perf loss unless your code is mostly using memo fields.
Loosing Binary Index will make a big speed loss if you have indeces in
deleted() and have large tables on a networked machine. So a lot
depends on your present usage of vfp and the load of data you are
slinging.
Still, using another product updating my production tables gives a
perhaps some kinks in it. Unless data entry in the other product in
unavoidable, I'd look for an easy import/export mechanism for selected
tables (if this is used for reporting or something similar).
my 0.02 EUR
thomas

Hi Everyone, Thanks in advance for the help.
I have another product that I'm interested in using that only reads
DBF's in FOX2X format.
If I convert all my tables back to FOX2X format, will the performance
of my applications suffer? I realize that certain data types such as
integer and datetime won't be supported but I can live with that.
My tables are not in a DBC. Are there any problems I should be aware
of in moving my data back to FOX2X format?
Many thanks,
Jeff

Dan Freeman

2010-08-20 16:35:29 UTC

Permalink

If, as you previously said, you are not using DBCs you are not likely
to be using the later data features the VFP oledb provider is intended
to expose.

That said, VFP's oledb provider (vfpoledb.dll) is basically most of the
Foxpro data engine in an object wrapper. (The help file has a list of
unsupported commands/functions.) It works fine in situations where it
is needed.

If plain Jane DBF provides the functionality you need, I think using
vfpoledb would be a little like "all I have is a hammer so that looks
like a nail". <s>

If you intend to use later data features and the 3rd party app you're
using can support OLEDB data sources, then fine. That would be a way to
go. I just don't see anything in what you've said so far that would
indicate that need.

Dan

Post by Jeff Grippe
Hi Everyone, I got this reply and wrote the following on the Google
group. If anyone has anything else to add to this or about ADO
specifically, I'd like to know.
Thanks again
Thanks for the reply.
We do use memo fields but there isn't a great deal of code that deals
with them. I some important places we do have indexes on EMPTY(<MEMO
FIELD>) so that we can quickly extract records with memos (a
minority)
Also from what I remember (and my memory isn't what it used to be),
we
were using indexes on DELETED() to speed up queries even back in the
Fox2x DOS days.
The other product that I'm going to use apparently stopped at FOX2X
format because after that, the format when proprietary (or they
didn't
want to do the work to change their product). They can access VFP 9
data using ADO connections and that actually could work. I haven't
decided which way to go.
I assume that using ADO for my queries give me access to rushmore and
doesn't leave me a the mercy of how well they've implemented query
optimization.
For now, I'm only looking at queries to fetch data to feed a web
site.
Even if I decide to use this tool for the parts of my web site that
actually take in data, I can have the data entered into a temporary
table and then have my FoxWeb applications stick it into the DBF's
using real VFP.
If I decide to write desktop applications with this software then I
will need to decide what to do with my data.
If you know anything about ADO that you can share, please do. I've
never worked with it before.
Thanks again.
- Hide quoted text -

Jeff Grippe

2010-08-23 12:51:47 UTC

Permalink

Post by Dan Freeman
If, as you previously said, you are not using DBCs you are not likely
to be using the later data features the VFP oledb provider is intended
to expose.
That said, VFP's oledb provider (vfpoledb.dll) is basically most of the
Foxpro data engine in an object wrapper. (The help file has a list of
unsupported commands/functions.) It works fine in situations where it
is needed.
If plain Jane DBF provides the functionality you need, I think using
vfpoledb would be a little like "all I have is a hammer so that looks
like a nail". <s>
If you intend to use later data features and the 3rd party app you're
using can support OLEDB data sources, then fine. That would be a way to
go. I just don't see anything in what you've said so far that would
indicate that need.
Dan

I guess in the long run, it depends on what we are going to do in the
long run.

I wish that back when we were having the "where do we go from here?"
threads, more people from smaller shops would have expressed opinions.

If I wasn't worried about hitting a point in time where I have OS's
that won't run it, VFP would be fine to stick with.

Dot Net seems like a big expense, big learning curve, and big
conversion which can't be done piece by piece.

A database system that talks to DBF's, Like Alpha 5 does, allows us to
do module by module conversion leaving the VFP ones running until that
A5 ones are ready.

This all presupposes that A5 and VFP get along once you have Multi-
User apps running on both platforms.

Jeff