Moving from VFP 6 to VFP 9

We currently support Visual AccountMate for a client of ours, which is
accounting software written in VFP. We do a lot of reading from and
writing to VAM data structures from outside VAM itself. The VAM version
our client has been using, LAN 5, was written in VFP 6 and that's what
we've used to talk to its data structures and for our own custom
development work for this client as well.

We are planning to install a newer version of VAM, also LAN (VAM also
has a SQL Server-based product but we are not doing that upgrade now
although we will in the future, I'm sure) that was written in VFP 9, and
would like to know if we should expect changes in data structure
significant enough to cause our VFP 6 programs to be unable to read from
and write to VFP 9 tables. Obviously we are planning to upgrade our own
VFP to 9 but we're trying to figure out if we can get away with doing
the VAM upgrade before doing the VFP upgrade for ourselves and for our
client.

Thanks in advance - detailed replies, e.g, "this will work, but that
won't" are most welcomed.

-S-

Craig
Wed Mar 29 10:31:06 CST 2006

I have no experience with VAM, but is definately possible that your VFP 6.0
code will not be able to access VFP 9.0 tables.

--
Craig Berntson
MCSD, Visual FoxPro MVP
www.craigberntson.com
Salt Lake City Fox User Group
www.slcfox.org
www.foxcentral.net


"Steve Freides" <steve@fridayscomputer.com> wrote in message
news:48vqluFkt8m4U1@individual.net...
> We currently support Visual AccountMate for a client of ours, which is
> accounting software written in VFP. We do a lot of reading from and
> writing to VAM data structures from outside VAM itself. The VAM version
> our client has been using, LAN 5, was written in VFP 6 and that's what
> we've used to talk to its data structures and for our own custom
> development work for this client as well.
>
> We are planning to install a newer version of VAM, also LAN (VAM also has
> a SQL Server-based product but we are not doing that upgrade now although
> we will in the future, I'm sure) that was written in VFP 9, and would like
> to know if we should expect changes in data structure significant enough
> to cause our VFP 6 programs to be unable to read from and write to VFP 9
> tables. Obviously we are planning to upgrade our own VFP to 9 but we're
> trying to figure out if we can get away with doing the VAM upgrade before
> doing the VFP upgrade for ourselves and for our client.
>
> Thanks in advance - detailed replies, e.g, "this will work, but that
> won't" are most welcomed.
>
> -S-
>

Dan
Wed Mar 29 10:51:44 CST 2006

I am curious as to reasons why VFP 6 code could not access VFP 9 tables? I
have been converting our VFP6 apps to VFP 9 and have had no compatibility
issues with the tables.

I was unaware of any table differences between VFP 6 and 9.


"Craig Berntson" <iamcraig@iamcraigberntson.com> wrote in message
news:eM1$u40UGHA.2704@tk2msftngp13.phx.gbl...
> I have no experience with VAM, but is definately possible that your VFP
6.0
> code will not be able to access VFP 9.0 tables.
>
> --
> Craig Berntson
> MCSD, Visual FoxPro MVP
> www.craigberntson.com
> Salt Lake City Fox User Group
> www.slcfox.org
> www.foxcentral.net
>
>
> "Steve Freides" <steve@fridayscomputer.com> wrote in message
> news:48vqluFkt8m4U1@individual.net...
> > We currently support Visual AccountMate for a client of ours, which is
> > accounting software written in VFP. We do a lot of reading from and
> > writing to VAM data structures from outside VAM itself. The VAM version
> > our client has been using, LAN 5, was written in VFP 6 and that's what
> > we've used to talk to its data structures and for our own custom
> > development work for this client as well.
> >
> > We are planning to install a newer version of VAM, also LAN (VAM also
has
> > a SQL Server-based product but we are not doing that upgrade now
although
> > we will in the future, I'm sure) that was written in VFP 9, and would
like
> > to know if we should expect changes in data structure significant enough
> > to cause our VFP 6 programs to be unable to read from and write to VFP 9
> > tables. Obviously we are planning to upgrade our own VFP to 9 but we're
> > trying to figure out if we can get away with doing the VAM upgrade
before
> > doing the VFP upgrade for ourselves and for our client.
> >
> > Thanks in advance - detailed replies, e.g, "this will work, but that
> > won't" are most welcomed.
> >
> > -S-
> >
>
>

Dan
Wed Mar 29 10:59:56 CST 2006

As Craig says, it's possible in VFP9 to create DBF files that can't be
accessed by prior versions. Since VFP6, they've added numerous database
features: Blob data type, AUTOINC, DBCevents, etc.

If VAM used any of these new features, your VFP6 apps will not be able to
open the data.

It's also possible they didn't use these new features. <s> Vertical market
apps (like VAM) tend to be conservative. We don't use any of the new
database features, for example, because many of our clients have huge
investments in reporting systems that rely on ODBC access to the data. The
ODBC driver hasn't been updated since VFP6.

You could create a little VFP6 app that opens all the VFP9 tables through
ODBC easily enough. That would tell you right away whether VFP6 can continue
to be used. <g>

Dan


Steve Freides wrote:
> We currently support Visual AccountMate for a client of ours, which is
> accounting software written in VFP. We do a lot of reading from and
> writing to VAM data structures from outside VAM itself. The VAM
> version our client has been using, LAN 5, was written in VFP 6 and
> that's what we've used to talk to its data structures and for our own
> custom development work for this client as well.
>
> We are planning to install a newer version of VAM, also LAN (VAM also
> has a SQL Server-based product but we are not doing that upgrade now
> although we will in the future, I'm sure) that was written in VFP 9,
> and would like to know if we should expect changes in data structure
> significant enough to cause our VFP 6 programs to be unable to read
> from and write to VFP 9 tables. Obviously we are planning to upgrade
> our own VFP to 9 but we're trying to figure out if we can get away
> with doing the VAM upgrade before doing the VFP upgrade for ourselves
> and for our client.
>
> Thanks in advance - detailed replies, e.g, "this will work, but that
> won't" are most welcomed.
>
> -S-

Cat
Wed Mar 29 12:10:28 CST 2006

Hi,

VAMLAN 6.5 does not use any of the new VFP 9 data features that would cause
problems for your VFP 6 programs.

The thing that may get you in trouble are table stucture changes between VAM
versions. They have added some new fields and you may need to accomodate
that in your code.

Cat

"Steve Freides" <steve@fridayscomputer.com> wrote in message
news:48vqluFkt8m4U1@individual.net...
> We currently support Visual AccountMate for a client of ours, which is
> accounting software written in VFP. We do a lot of reading from and
> writing to VAM data structures from outside VAM itself. The VAM version
> our client has been using, LAN 5, was written in VFP 6 and that's what
> we've used to talk to its data structures and for our own custom
> development work for this client as well.
>
> We are planning to install a newer version of VAM, also LAN (VAM also has
> a SQL Server-based product but we are not doing that upgrade now although
> we will in the future, I'm sure) that was written in VFP 9, and would like
> to know if we should expect changes in data structure significant enough
> to cause our VFP 6 programs to be unable to read from and write to VFP 9
> tables. Obviously we are planning to upgrade our own VFP to 9 but we're
> trying to figure out if we can get away with doing the VAM upgrade before
> doing the VFP upgrade for ourselves and for our client.
>
> Thanks in advance - detailed replies, e.g, "this will work, but that
> won't" are most welcomed.
>
> -S-
>

Paul
Wed Mar 29 19:22:29 CST 2006

I think it will work fine, except for cases in which there are new field
types. Autoincrementing integer is the only one that comes immediately to
mind. Oh, and blob of course, and varchar. Maybe binary memos? I don't
remember about those.

But I think if the VFP9 tables don't have those fields, you should be able
to work with them in VFP6. Try it and see.

You might also want to check for new database features, if you're using a
database.



"Dan" <delliott@midwestecoat.com> wrote in message
news:O1QgQE1UGHA.1564@TK2MSFTNGP11.phx.gbl...
>I am curious as to reasons why VFP 6 code could not access VFP 9 tables? I
> have been converting our VFP6 apps to VFP 9 and have had no compatibility
> issues with the tables.
>
> I was unaware of any table differences between VFP 6 and 9.
>
>
> "Craig Berntson" <iamcraig@iamcraigberntson.com> wrote in message
> news:eM1$u40UGHA.2704@tk2msftngp13.phx.gbl...
>> I have no experience with VAM, but is definately possible that your VFP
> 6.0
>> code will not be able to access VFP 9.0 tables.
>>
>> --
>> Craig Berntson
>> MCSD, Visual FoxPro MVP
>> www.craigberntson.com
>> Salt Lake City Fox User Group
>> www.slcfox.org
>> www.foxcentral.net
>>
>>
>> "Steve Freides" <steve@fridayscomputer.com> wrote in message
>> news:48vqluFkt8m4U1@individual.net...
>> > We currently support Visual AccountMate for a client of ours, which is
>> > accounting software written in VFP. We do a lot of reading from and
>> > writing to VAM data structures from outside VAM itself. The VAM
>> > version
>> > our client has been using, LAN 5, was written in VFP 6 and that's what
>> > we've used to talk to its data structures and for our own custom
>> > development work for this client as well.
>> >
>> > We are planning to install a newer version of VAM, also LAN (VAM also
> has
>> > a SQL Server-based product but we are not doing that upgrade now
> although
>> > we will in the future, I'm sure) that was written in VFP 9, and would
> like
>> > to know if we should expect changes in data structure significant
>> > enough
>> > to cause our VFP 6 programs to be unable to read from and write to VFP
>> > 9
>> > tables. Obviously we are planning to upgrade our own VFP to 9 but
>> > we're
>> > trying to figure out if we can get away with doing the VAM upgrade
> before
>> > doing the VFP upgrade for ourselves and for our client.
>> >
>> > Thanks in advance - detailed replies, e.g, "this will work, but that
>> > won't" are most welcomed.
>> >
>> > -S-
>> >
>>
>>
>
>

Steve
Wed Mar 29 20:17:31 CST 2006

"Cat Chowdy" <catchowdyathotmaildotcom> wrote in message
news:%23AmISw1UGHA.1160@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> VAMLAN 6.5 does not use any of the new VFP 9 data features that would
> cause problems for your VFP 6 programs.
>
> The thing that may get you in trouble are table stucture changes
> between VAM versions. They have added some new fields and you may
> need to accomodate that in your code.

OK, this sounds good to me. We'll set up a test environment in which to
try this.

> Cat
>
> "Steve Freides" <steve@fridayscomputer.com> wrote in message
> news:48vqluFkt8m4U1@individual.net...
>> We currently support Visual AccountMate for a client of ours, which
>> is accounting software written in VFP. We do a lot of reading from
>> and writing to VAM data structures from outside VAM itself. The VAM
>> version our client has been using, LAN 5, was written in VFP 6 and
>> that's what we've used to talk to its data structures and for our own
>> custom development work for this client as well.
>>
>> We are planning to install a newer version of VAM, also LAN (VAM also
>> has a SQL Server-based product but we are not doing that upgrade now
>> although we will in the future, I'm sure) that was written in VFP 9,
>> and would like to know if we should expect changes in data structure
>> significant enough to cause our VFP 6 programs to be unable to read
>> from and write to VFP 9 tables. Obviously we are planning to upgrade
>> our own VFP to 9 but we're trying to figure out if we can get away
>> with doing the VAM upgrade before doing the VFP upgrade for ourselves
>> and for our client.
>>
>> Thanks in advance - detailed replies, e.g, "this will work, but that
>> won't" are most welcomed.
>>
>> -S-
>>
>
>

Fred
Thu Mar 30 00:30:07 CST 2006

Besides what Paul told you about, there may also be .DBC events, and won't
work in VFP6. If they're enabled, I don't even think you could open the
database.

--
Fred
Microsoft Visual FoxPro MVP


"Dan" <delliott@midwestecoat.com> wrote in message
news:O1QgQE1UGHA.1564@TK2MSFTNGP11.phx.gbl...
>I am curious as to reasons why VFP 6 code could not access VFP 9 tables? I
> have been converting our VFP6 apps to VFP 9 and have had no compatibility
> issues with the tables.
>
> I was unaware of any table differences between VFP 6 and 9.
>
>
> "Craig Berntson" <iamcraig@iamcraigberntson.com> wrote in message
> news:eM1$u40UGHA.2704@tk2msftngp13.phx.gbl...
>> I have no experience with VAM, but is definately possible that your VFP
> 6.0
>> code will not be able to access VFP 9.0 tables.
>>
>> --
>> Craig Berntson
>> MCSD, Visual FoxPro MVP
>> www.craigberntson.com
>> Salt Lake City Fox User Group
>> www.slcfox.org
>> www.foxcentral.net
>>
>>
>> "Steve Freides" <steve@fridayscomputer.com> wrote in message
>> news:48vqluFkt8m4U1@individual.net...
>> > We currently support Visual AccountMate for a client of ours, which is
>> > accounting software written in VFP. We do a lot of reading from and
>> > writing to VAM data structures from outside VAM itself. The VAM
>> > version
>> > our client has been using, LAN 5, was written in VFP 6 and that's what
>> > we've used to talk to its data structures and for our own custom
>> > development work for this client as well.
>> >
>> > We are planning to install a newer version of VAM, also LAN (VAM also
> has
>> > a SQL Server-based product but we are not doing that upgrade now
> although
>> > we will in the future, I'm sure) that was written in VFP 9, and would
> like
>> > to know if we should expect changes in data structure significant
>> > enough
>> > to cause our VFP 6 programs to be unable to read from and write to VFP
>> > 9
>> > tables. Obviously we are planning to upgrade our own VFP to 9 but
>> > we're
>> > trying to figure out if we can get away with doing the VAM upgrade
> before
>> > doing the VFP upgrade for ourselves and for our client.
>> >
>> > Thanks in advance - detailed replies, e.g, "this will work, but that
>> > won't" are most welcomed.
>> >
>> > -S-
>> >
>>
>>
>
>

Imaginecorp
Thu Mar 30 06:11:34 CST 2006

Hello Steve:
Apart from what Cat wrote, the only thing I would worry about are the Select
... Group by statement in your VFP 6 code. VFP9 requires all fields in the
Select to be in your Group By clause. Also if running on an XP machine your
forms may inherit the Themes if it is set to .T.
Apart from this you should have no problems. Your app will run a little
faster as well
Mohammed



"Steve Freides" <steve@fridayscomputer.com> wrote in message
news:48vqluFkt8m4U1@individual.net...
> We currently support Visual AccountMate for a client of ours, which is
> accounting software written in VFP. We do a lot of reading from and
> writing to VAM data structures from outside VAM itself. The VAM version
> our client has been using, LAN 5, was written in VFP 6 and that's what
> we've used to talk to its data structures and for our own custom
> development work for this client as well.
>
> We are planning to install a newer version of VAM, also LAN (VAM also has
> a SQL Server-based product but we are not doing that upgrade now although
> we will in the future, I'm sure) that was written in VFP 9, and would like
> to know if we should expect changes in data structure significant enough
> to cause our VFP 6 programs to be unable to read from and write to VFP 9
> tables. Obviously we are planning to upgrade our own VFP to 9 but we're
> trying to figure out if we can get away with doing the VAM upgrade before
> doing the VFP upgrade for ourselves and for our client.
>
> Thanks in advance - detailed replies, e.g, "this will work, but that
> won't" are most welcomed.
>
> -S-
>

Villi
Thu Mar 30 06:13:58 CST 2006

Fred Taylor wrote:

> Besides what Paul told you about, there may also be .DBC
> events, and
> won't work in VFP6. If they're enabled, I don't even think you
> could
> open the database.

Even via ODBC?
--
The answer to the ethernal question is:
put a read events after the launch of the form

Craig
Thu Mar 30 10:25:58 CST 2006

Yes, even via ODBC, as the ODBC driver has not been updated since VFP 6.0.

--
Craig Berntson
MCSD, Visual FoxPro MVP
www.craigberntson.com
Salt Lake City Fox User Group
www.slcfox.org
www.foxcentral.net


"Villi Bernaroli" <a@b.c> wrote in message
news:OvJoxN$UGHA.5588@TK2MSFTNGP09.phx.gbl...
> Fred Taylor wrote:
>
>> Besides what Paul told you about, there may also be .DBC events, and
>> won't work in VFP6. If they're enabled, I don't even think you could
>> open the database.
>
> Even via ODBC?
> --
> The answer to the ethernal question is:
> put a read events after the launch of the form
>

Paul
Thu Mar 30 14:32:59 CST 2006

Oh, and binary indexes, too.

"Paul Pedersen" <nospam@no.spam> wrote in message
news:uz9Enh5UGHA.5996@TK2MSFTNGP10.phx.gbl...
>I think it will work fine, except for cases in which there are new field
>types. Autoincrementing integer is the only one that comes immediately to
>mind. Oh, and blob of course, and varchar. Maybe binary memos? I don't
>remember about those.
>
> But I think if the VFP9 tables don't have those fields, you should be able
> to work with them in VFP6. Try it and see.
>
> You might also want to check for new database features, if you're using a
> database.
>
>
>
> "Dan" <delliott@midwestecoat.com> wrote in message
> news:O1QgQE1UGHA.1564@TK2MSFTNGP11.phx.gbl...
>>I am curious as to reasons why VFP 6 code could not access VFP 9 tables?
>>I
>> have been converting our VFP6 apps to VFP 9 and have had no
>> compatibility
>> issues with the tables.
>>
>> I was unaware of any table differences between VFP 6 and 9.
>>
>>
>> "Craig Berntson" <iamcraig@iamcraigberntson.com> wrote in message
>> news:eM1$u40UGHA.2704@tk2msftngp13.phx.gbl...
>>> I have no experience with VAM, but is definately possible that your VFP
>> 6.0
>>> code will not be able to access VFP 9.0 tables.
>>>
>>> --
>>> Craig Berntson
>>> MCSD, Visual FoxPro MVP
>>> www.craigberntson.com
>>> Salt Lake City Fox User Group
>>> www.slcfox.org
>>> www.foxcentral.net
>>>
>>>
>>> "Steve Freides" <steve@fridayscomputer.com> wrote in message
>>> news:48vqluFkt8m4U1@individual.net...
>>> > We currently support Visual AccountMate for a client of ours, which is
>>> > accounting software written in VFP. We do a lot of reading from and
>>> > writing to VAM data structures from outside VAM itself. The VAM
>>> > version
>>> > our client has been using, LAN 5, was written in VFP 6 and that's what
>>> > we've used to talk to its data structures and for our own custom
>>> > development work for this client as well.
>>> >
>>> > We are planning to install a newer version of VAM, also LAN (VAM also
>> has
>>> > a SQL Server-based product but we are not doing that upgrade now
>> although
>>> > we will in the future, I'm sure) that was written in VFP 9, and would
>> like
>>> > to know if we should expect changes in data structure significant
>>> > enough
>>> > to cause our VFP 6 programs to be unable to read from and write to VFP
>>> > 9
>>> > tables. Obviously we are planning to upgrade our own VFP to 9 but
>>> > we're
>>> > trying to figure out if we can get away with doing the VAM upgrade
>> before
>>> > doing the VFP upgrade for ourselves and for our client.
>>> >
>>> > Thanks in advance - detailed replies, e.g, "this will work, but that
>>> > won't" are most welcomed.
>>> >
>>> > -S-
>>> >
>>>
>>>
>>
>>
>
>

Steve
Thu Mar 30 20:44:25 CST 2006

"Fred Taylor" <ftaylor@mvps.org!REMOVE> wrote in message
news:OlgocM8UGHA.5288@TK2MSFTNGP14.phx.gbl...
> Besides what Paul told you about, there may also be .DBC events, and
> won't work in VFP6. If they're enabled, I don't even think you could
> open the database.

Everyone, I installed VAM LAN 6 today and did a quick open of the main
database and a browse of a few of the tables - so far, no problem. The
main developer on this will be testing his code tomorrow in a test
environment and I'll report back on how it goes and if there are any
problems.

-S-

> --
> Fred
> Microsoft Visual FoxPro MVP
>
>
> "Dan" <delliott@midwestecoat.com> wrote in message
> news:O1QgQE1UGHA.1564@TK2MSFTNGP11.phx.gbl...
>>I am curious as to reasons why VFP 6 code could not access VFP 9
>>tables? I
>> have been converting our VFP6 apps to VFP 9 and have had no
>> compatibility
>> issues with the tables.
>>
>> I was unaware of any table differences between VFP 6 and 9.
>>
>>
>> "Craig Berntson" <iamcraig@iamcraigberntson.com> wrote in message
>> news:eM1$u40UGHA.2704@tk2msftngp13.phx.gbl...
>>> I have no experience with VAM, but is definately possible that your
>>> VFP
>> 6.0
>>> code will not be able to access VFP 9.0 tables.
>>>
>>> --
>>> Craig Berntson
>>> MCSD, Visual FoxPro MVP
>>> www.craigberntson.com
>>> Salt Lake City Fox User Group
>>> www.slcfox.org
>>> www.foxcentral.net
>>>
>>>
>>> "Steve Freides" <steve@fridayscomputer.com> wrote in message
>>> news:48vqluFkt8m4U1@individual.net...
>>> > We currently support Visual AccountMate for a client of ours,
>>> > which is
>>> > accounting software written in VFP. We do a lot of reading from
>>> > and
>>> > writing to VAM data structures from outside VAM itself. The VAM
>>> > version
>>> > our client has been using, LAN 5, was written in VFP 6 and that's
>>> > what
>>> > we've used to talk to its data structures and for our own custom
>>> > development work for this client as well.
>>> >
>>> > We are planning to install a newer version of VAM, also LAN (VAM
>>> > also
>> has
>>> > a SQL Server-based product but we are not doing that upgrade now
>> although
>>> > we will in the future, I'm sure) that was written in VFP 9, and
>>> > would
>> like
>>> > to know if we should expect changes in data structure significant
>>> > enough
>>> > to cause our VFP 6 programs to be unable to read from and write to
>>> > VFP 9
>>> > tables. Obviously we are planning to upgrade our own VFP to 9 but
>>> > we're
>>> > trying to figure out if we can get away with doing the VAM upgrade
>> before
>>> > doing the VFP upgrade for ourselves and for our client.
>>> >
>>> > Thanks in advance - detailed replies, e.g, "this will work, but
>>> > that
>>> > won't" are most welcomed.
>>> >
>>> > -S-
>>> >
>>>
>>>
>>
>>
>
>

Peter
Fri Apr 07 18:25:17 CDT 2006

In article <#F2TWM$UGHA.4740@TK2MSFTNGP14.phx.gbl>, imaginecorp@msn.com
says...
> Also if running on an XP machine your
> forms may inherit the Themes if it is set to .T.

Where is this setting?


thanks

pete

Paul
Fri Apr 07 19:08:02 CDT 2006

_SCREEN.THEMES and/or FORM.THEMES


"Peter Huish" <huish@ozemail.com.au> wrote in message
news:MPG.1ea19fd1a216f55798981f@news.easynews.com...
> In article <#F2TWM$UGHA.4740@TK2MSFTNGP14.phx.gbl>, imaginecorp@msn.com
> says...
>> Also if running on an XP machine your
>> forms may inherit the Themes if it is set to .T.
>
> Where is this setting?
>
>
> thanks
>
> pete