vfp9 speed issues

[John Davy]

Hi

In recent months we have recompiled our vfp6 application in vfp9 and are in
the process of rolling this out to our clients.

We have a number of clients advising us of a substantial degradation in the
speed of some of the longer processes

Is this characteristic of vfp9 or is there some new option that is likely
to cause this.

I would be interested to hear if anyone else has had a similar problem

The client I am currently dealing with has 13 users linked into the foxpro
database on a win2003 server.

Cheers
John Davy

[Man-wai Chang ToDie (33.6k)]

Post by John Davy
We have a number of clients advising us of a substantial degradation in
the speed of some of the longer processes
The client I am currently dealing with has 13 users linked into the
foxpro database on a win2003 server.

Are their virus-scanners scanning VFP's data files (*.DBF, *.CDX, *.IDX,
...) and other files? Or are you using a database server to store data?

[John Davy]

Hi Man-wai

Yes we did check that one but with no luck - thanks for the suggestion
anyway

Cheers
John

Post by Man-wai Chang ToDie (33.6k)

Post by John Davy
We have a number of clients advising us of a substantial degradation in
the speed of some of the longer processes
The client I am currently dealing with has 13 users linked into the
foxpro database on a win2003 server.

Are their virus-scanners scanning VFP's data files (*.DBF, *.CDX, *.IDX,
...) and other files? Or are you using a database server to store data?
--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.5
^ ^ 12:59:01 up 19 days 21:49 3 users load average: 1.00 1.02 1.00
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa/

[Paul Pedersen]

Not that I've heard of. In my experience, v9 has been faster.

What's happening in those slow processes?

Post by John Davy
Hi
In recent months we have recompiled our vfp6 application in vfp9 and are
in the process of rolling this out to our clients.
We have a number of clients advising us of a substantial degradation in
the speed of some of the longer processes
Is this characteristic of vfp9 or is there some new option that is likely
to cause this.
I would be interested to hear if anyone else has had a similar problem
The client I am currently dealing with has 13 users linked into the foxpro
database on a win2003 server.
Cheers
John Davy

[John Davy]

Hi Paul

Thanks for the reply

The slow processes?..
Just posting account payments etc, just reads and writes - no printing or
anything fancy
- they are the same reads and writes that happened more quickly under vfp6

Is vfp9 more sensitive to some network settings?

cheers
John

Post by Paul Pedersen
Not that I've heard of. In my experience, v9 has been faster.
What's happening in those slow processes?

Post by John Davy
Hi
In recent months we have recompiled our vfp6 application in vfp9 and are
in the process of rolling this out to our clients.
We have a number of clients advising us of a substantial degradation in
the speed of some of the longer processes
Is this characteristic of vfp9 or is there some new option that is
likely to cause this.
I would be interested to hear if anyone else has had a similar problem
The client I am currently dealing with has 13 users linked into the
foxpro database on a win2003 server.
Cheers
John Davy

[Fabio Lenzarini]

hi, sorry for my bad english...

If you d'ont modify at run rime the database, try to put "read only" the
3 files: .DBC, .DCX and .CDX

Fabio Lenzarini
www.softup.it
Italy

Post by John Davy
Hi
In recent months we have recompiled our vfp6 application in vfp9 and are
in the process of rolling this out to our clients.
We have a number of clients advising us of a substantial degradation in
the speed of some of the longer processes
Is this characteristic of vfp9 or is there some new option that is
likely to cause this.
I would be interested to hear if anyone else has had a similar problem
The client I am currently dealing with has 13 users linked into the
foxpro database on a win2003 server.
Cheers
John Davy

[John Davy]

Hi Fabio

This is an interesting idea - is there some documentation to suggest that
this would make some difference?

It would be a bit more difficult to manage this because the program auto
updates it database with each version upgrade.
although if it did prove helpful it wouldn't be impossible to remove the
read-only attribute just prior to the data upgrade and replace it afterwards

I appreciate everyone's help and suggestions so far
I am on leave for a few days now but will check for new posts when I get
back.

Cheers
John

Post by Fabio Lenzarini
hi, sorry for my bad english...
If you d'ont modify at run rime the database, try to put "read only" the 3
files: .DBC, .DCX and .CDX
Fabio Lenzarini
www.softup.it
Italy

Post by John Davy
Hi
In recent months we have recompiled our vfp6 application in vfp9 and are
in the process of rolling this out to our clients.
We have a number of clients advising us of a substantial degradation in
the speed of some of the longer processes
Is this characteristic of vfp9 or is there some new option that is
likely to cause this.
I would be interested to hear if anyone else has had a similar problem
The client I am currently dealing with has 13 users linked into the
foxpro database on a win2003 server.
Cheers
John Davy

[Fabio Lenzarini]

I've only found a document where some people suggest to put read only
the EXE, but in my application the .EXE is local...

i've only try this for disperation... and the time to access to the
database is better the the original RW property...

sorry for my english, i've study french at scool (and Italian.. :-) )

Fabio Lenzarini

Post by John Davy
Hi Fabio
This is an interesting idea - is there some documentation to suggest
that this would make some difference?
It would be a bit more difficult to manage this because the program auto
updates it database with each version upgrade.
although if it did prove helpful it wouldn't be impossible to remove
the read-only attribute just prior to the data upgrade and replace it
afterwards
I appreciate everyone's help and suggestions so far
I am on leave for a few days now but will check for new posts when I get
back.
Cheers
John

Post by Fabio Lenzarini
hi, sorry for my bad english...
If you d'ont modify at run rime the database, try to put "read only"
the 3 files: .DBC, .DCX and .CDX
Fabio Lenzarini
www.softup.it
Italy

Post by John Davy
Hi
In recent months we have recompiled our vfp6 application in vfp9 and
are in the process of rolling this out to our clients.
We have a number of clients advising us of a substantial degradation
in the speed of some of the longer processes
Is this characteristic of vfp9 or is there some new option that is
likely to cause this.
I would be interested to hear if anyone else has had a similar problem
The client I am currently dealing with has 13 users linked into the
foxpro database on a win2003 server.
Cheers
John Davy

[D L]

Fabio, I've been working for over a month on this issue. Marking the DBC, DCT, DCX files as readonly sped up multiusers by 30-45%. Thanks.

Post by John Davy
Hi
In recent months we have recompiled our vfp6 application in vfp9 and are in
the process of rolling this out to our clients.
We have a number of clients advising us of a substantial degradation in the
speed of some of the longer processes
Is this characteristic of vfp9 or is there some new option that is likely
to cause this.
I would be interested to hear if anyone else has had a similar problem
The client I am currently dealing with has 13 users linked into the foxpro
database on a win2003 server.
Cheers
John Davy

Post by Man-wai Chang ToDie (33.6k)

Post by John Davy
The client I am currently dealing with has 13 users linked into the
foxpro database on a win2003 server.

Are their virus-scanners scanning VFP's data files (*.DBF, *.CDX, *.IDX,
...) and other files? Or are you using a database server to store data?
--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.5
^ ^ 12:59:01 up 19 days 21:49 3 users load average: 1.00 1.02 1.00
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa/

Post by John Davy
Not that I have heard of. In my experience, v9 has been faster.
What's happening in those slow processes?

Post by Fabio Lenzarini
hi, sorry for my bad english...
If you d'ont modify at run rime the database, try to put "read only" the
3 files: .DBC, .DCX and .CDX
Fabio Lenzarini
www.softup.it
Italy

Post by John Davy
Hi Paul
Thanks for the reply
The slow processes?..
Just posting account payments etc, just reads and writes - no printing or
anything fancy
- they are the same reads and writes that happened more quickly under vfp6
Is vfp9 more sensitive to some network settings?
cheers
John

Post by John Davy
Hi Man-wai
Yes we did check that one but with no luck - thanks for the suggestion
anyway
Cheers
John

Post by John Davy
Hi Fabio
This is an interesting idea - is there some documentation to suggest that
this would make some difference?
It would be a bit more difficult to manage this because the program auto
updates it database with each version upgrade.
although if it did prove helpful it wouldn't be impossible to remove the
read-only attribute just prior to the data upgrade and replace it afterwards
I appreciate everyone's help and suggestions so far
I am on leave for a few days now but will check for new posts when I get
back.
Cheers
John

Post by Olaf Doschke
Did you apply SP2 or did you use
the naked VFP9 installation?
There was a bug, that rushmore
wouldn't use indexes on expressions
with STR(), that was fixed by SP1.
Otherwise reports can slow down
because of the advanced processing
with Report*.apps.
Bye, Olaf.

Post by Fabio Lenzarini
I've only found a document where some people suggest to put read only
the EXE, but in my application the .EXE is local...
i've only try this for disperation... and the time to access to the
database is better the the original RW property...
sorry for my english, i've study french at scool (and Italian.. :-) )
Fabio Lenzarini

Post by Dan Freeman
If you're coming from VFP6, you're unlikely to have code that handles and/or
disables SET TABLEVALIDATE. If you're opening/closing often, that can slow
you down a LOT.
Turn it off until you've had time to fully studied it and you're sure you
need what it does.
Dan

Post by Mark Burgum
John
it has been a while since we moved up from VFP6, however i seem to recall
that there used to be work around to change cursor created by sql select
into read write ones. in VFP 7 they added a readwrite clause to the select
statements, however i recall that when we upgraded all the parts of our
package that used the old cheat, where very slow. maybe thats one of your
problems.

Post by K***@hotmail.com
You should make sure the expression you are selecting matches exactly
your index. For example, suppose you have an index on lastname
+firstname. You might want to select all records where
lastname="CLARK", but your select would need to be
Select * from file where lastname+firstname="CLARK"
If you are not sure exactly what is slowing the program down, the
Coverage Profiler is a great tool. That will tell you exactly where
the bottlenecks are and let you set priorities of what needs to be
changed first.
Regards,
Kevin Clark

Post by John Davy
Hi Olaf
Sorry for the delay in replying, I have been away for a while
I am using sp2 so that isn't the problem,
and not many sql statements so I don't think rushmore optimization is the
issue.
The clients reporting the issue have pointed to problems with processes that
are write intensive
and it appears that this is where the problem seems to be. I would typically
use either append blank, and replace
or fill an array or object and insert from the array or object
Thanks for your help so far.
Cheers
John

Post by John Davy
Hi Dan
I have already got some code to disable the tablevalidate and I typically
open all tables needed for a form in the dataenvironment when opening a form
and leave these open till the form closes (most forms have a private
datasession).
I use an external routine to validate the tables when it looks that there
may be a problem.
I do the majority of writes within a 'begin...end transaction' and using
tablebuffering = 2
Thanks for your help
Cheers
John

Post by John Davy
Hi Kevin
I remember reading that there was a coverage profiler but I had forgotten
all about it
I will give this one a go and see what it turns up
Thanks for the prompt
Cheers
John

Post by Craig Berntson
Rushmore is used in more places than SQL SELECT.
Copy the DBC locally. I've seen VFP slowdown when too many users try to
simultaneously hit the same DBC.
--
Craig Berntson
Microsoft MVP
-------------
Submitted via EggHeadCafe
Microsoft ASP.NET For Beginners
http://www.eggheadcafe.com/training-topic-area/ASP-NET/7/ASP.aspx

[Olaf Doschke]

Did you apply SP2 or did you use
the naked VFP9 installation?

There was a bug, that rushmore
wouldn't use indexes on expressions
with STR(), that was fixed by SP1.

Otherwise reports can slow down
because of the advanced processing
with Report*.apps.

Bye, Olaf.

[John Davy]

Hi Olaf

Sorry for the delay in replying, I have been away for a while
I am using sp2 so that isn't the problem,
and not many sql statements so I don't think rushmore optimization is the
issue.

The clients reporting the issue have pointed to problems with processes that
are write intensive
and it appears that this is where the problem seems to be. I would typically
use either append blank, and replace
or fill an array or object and insert from the array or object

Thanks for your help so far.

Cheers
John

Post by Olaf Doschke
Did you apply SP2 or did you use
the naked VFP9 installation?
There was a bug, that rushmore
wouldn't use indexes on expressions
with STR(), that was fixed by SP1.
Otherwise reports can slow down
because of the advanced processing
with Report*.apps.
Bye, Olaf.

[Craig Berntson]

Rushmore is used in more places than SQL SELECT.

Copy the DBC locally. I've seen VFP slowdown when too many users try to
simultaneously hit the same DBC.
--
Craig Berntson
Microsoft MVP

-------------

Post by John Davy
Hi Olaf
Sorry for the delay in replying, I have been away for a while
I am using sp2 so that isn't the problem,
and not many sql statements so I don't think rushmore optimization is the
issue.
The clients reporting the issue have pointed to problems with processes
that are write intensive
and it appears that this is where the problem seems to be. I would
typically use either append blank, and replace
or fill an array or object and insert from the array or object
Thanks for your help so far.
Cheers
John

Post by Olaf Doschke
Did you apply SP2 or did you use
the naked VFP9 installation?
There was a bug, that rushmore
wouldn't use indexes on expressions
with STR(), that was fixed by SP1.
Otherwise reports can slow down
because of the advanced processing
with Report*.apps.
Bye, Olaf.

[Dan Freeman]

If you're coming from VFP6, you're unlikely to have code that handles and/or
disables SET TABLEVALIDATE. If you're opening/closing often, that can slow
you down a LOT.

Turn it off until you've had time to fully studied it and you're sure you
need what it does.

Dan

Post by John Davy
Hi
In recent months we have recompiled our vfp6 application in vfp9 and
are in the process of rolling this out to our clients.
We have a number of clients advising us of a substantial degradation
in the speed of some of the longer processes
Is this characteristic of vfp9 or is there some new option that is likely
to cause this.
I would be interested to hear if anyone else has had a similar problem
The client I am currently dealing with has 13 users linked into the
foxpro database on a win2003 server.
Cheers
John Davy

[John Davy]

Hi Dan

I have already got some code to disable the tablevalidate and I typically
open all tables needed for a form in the dataenvironment when opening a form
and leave these open till the form closes (most forms have a private
datasession).

I use an external routine to validate the tables when it looks that there
may be a problem.

I do the majority of writes within a 'begin...end transaction' and using
tablebuffering = 2

Thanks for your help

Cheers
John

Post by Dan Freeman
If you're coming from VFP6, you're unlikely to have code that handles
and/or disables SET TABLEVALIDATE. If you're opening/closing often, that
can slow you down a LOT.
Turn it off until you've had time to fully studied it and you're sure you
need what it does.
Dan

Post by John Davy
Hi
In recent months we have recompiled our vfp6 application in vfp9 and
are in the process of rolling this out to our clients.
We have a number of clients advising us of a substantial degradation
in the speed of some of the longer processes
Is this characteristic of vfp9 or is there some new option that is likely
to cause this.
I would be interested to hear if anyone else has had a similar problem
The client I am currently dealing with has 13 users linked into the
foxpro database on a win2003 server.
Cheers
John Davy

[Mark Burgum]

John

it has been a while since we moved up from VFP6, however i seem to recall
that there used to be work around to change cursor created by sql select
into read write ones. in VFP 7 they added a readwrite clause to the select
statements, however i recall that when we upgraded all the parts of our
package that used the old cheat, where very slow. maybe thats one of your
problems.

Post by John Davy
Hi
In recent months we have recompiled our vfp6 application in vfp9 and are
in the process of rolling this out to our clients.
We have a number of clients advising us of a substantial degradation in
the speed of some of the longer processes
Is this characteristic of vfp9 or is there some new option that is likely
to cause this.
I would be interested to hear if anyone else has had a similar problem
The client I am currently dealing with has 13 users linked into the foxpro
database on a win2003 server.
Cheers
John Davy

[K***@hotmail.com]

You should make sure the expression you are selecting matches exactly
your index. For example, suppose you have an index on lastname
+firstname. You might want to select all records where
lastname="CLARK", but your select would need to be

Select * from file where lastname+firstname="CLARK"

If you are not sure exactly what is slowing the program down, the
Coverage Profiler is a great tool. That will tell you exactly where
the bottlenecks are and let you set priorities of what needs to be
changed first.

Regards,
Kevin Clark

[John Davy]

Hi Kevin

I remember reading that there was a coverage profiler but I had forgotten
all about it
I'll give this one a go and see what it turns up

Thanks for the prompt

Cheers
John

Post by K***@hotmail.com
You should make sure the expression you are selecting matches exactly
your index. For example, suppose you have an index on lastname
+firstname. You might want to select all records where
lastname="CLARK", but your select would need to be
Select * from file where lastname+firstname="CLARK"
If you are not sure exactly what is slowing the program down, the
Coverage Profiler is a great tool. That will tell you exactly where
the bottlenecks are and let you set priorities of what needs to be
changed first.
Regards,
Kevin Clark