Problems saving effects entire app

Discussion:

(too old to reply)

Anonymous

2004-09-22 17:30:47 UTC

I have an application that was created with FoxPro for windows 3.1,
then was converted to FP Visual 6.0, then 7.0. Ever since the initial
conversion to visual, saving data had been a problem, especially
within scans. In order to save properly, I had to resort to a do-while
loop or slow the scan down with 'wait' clauses. This slows the app's
process down considerably and am getting complaints that FoxPro for
windows is faster. What can be done to improve it's speed within
scans/loops? I'm planning to upgrade the app to version 8.0. Will this
solve the saving problem? or are there suggestions as to what type of
programming to avoid when there is a saving problem?

Rick Bean

2004-09-22 18:44:16 UTC

Permalink

I'll assume you mean FPW 2.5/2.6 that ran on Windows 3.1x. How was this application converted? Did your users upgrade the hardware with the "new" version - especially memory? With each new version (9.0 will be out soon!), less and less emphasis has been placed on running the old xBase code "fast". Consider a rewrite - it's the only way to take advantage of the newer versions.

Rick

Post by Anonymous
I have an application that was created with FoxPro for windows 3.1,
then was converted to FP Visual 6.0, then 7.0. Ever since the initial
conversion to visual, saving data had been a problem, especially
within scans. In order to save properly, I had to resort to a do-while
loop or slow the scan down with 'wait' clauses. This slows the app's
process down considerably and am getting complaints that FoxPro for
windows is faster. What can be done to improve it's speed within
scans/loops? I'm planning to upgrade the app to version 8.0. Will this
solve the saving problem? or are there suggestions as to what type of
programming to avoid when there is a saving problem?

Lee Mitchell

2004-09-22 19:35:41 UTC

Permalink

Hi wipeout64:

To add to Rick's post, I would add a SYS(3050) function to the code to
optimize VFP's internal usage of memory. I assume they have upgraded
hardware since their FoxPro 2.x days. If you have a lot of RAM on a
machine, VFP can actually respond more slowly. See this article for more
info:
176483 PRB: Large Amounts of RAM Seem to Process Data Slowly
http://support.microsoft.com/?id=176483

You did not say if the exe was installed locally or on a server. If it is
located on a server, use the "tmpfiles=" switch in the Config.fpw file to
direct the VFP temp files to a folder on the workstations local hard drive.

Finally, you can run the code in the Coverage Profiler within the IDE to
locate the performace bottlenecks. See
191953 How To Use Coverage Profiler to Optimize App Performance
http://support.microsoft.com/?id=191953

I hope this helps.

This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

*-- VFP9 Public Beta Now Available!! --*
Download the VFP9 beta here: http://msdn.microsoft.com/vfoxpro/

*-- VFP8 HAS ARRIVED!! --*
Read about all the new features of VFP8 here:
http://www.universalthread.com/VisualFoxPro/News/VFP8Release.asp
Purchase VFP8 here:
http://shop.microsoft.com/Referral/Productinfo.asp?siteID=11518

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
- VFP5 Mainstream Support retired June 30th, 2003
- VFP6 Mainstream Support retired Sept. 30th, 2003

Post by Rick Bean
I'll assume you mean FPW 2.5/2.6 that ran on Windows 3.1x. How was this

application >converted? Did your users upgrade the hardware with the "new"
version - especially memory? >With each new version (9.0 will be out
soon!), less and less emphasis has been placed on >running the old xBase
code "fast". Consider a rewrite - it's the only way to take advantage of
the >newer versions.

Post by Rick Bean
Rick
I have an application that was created with FoxPro for windows 3.1,
then was converted to FP Visual 6.0, then 7.0. Ever since the initial
conversion to visual, saving data had been a problem, especially
within scans. In order to save properly, I had to resort to a do-while
loop or slow the scan down with 'wait' clauses. This slows the app's
process down considerably and am getting complaints that FoxPro for
windows is faster. What can be done to improve it's speed within
scans/loops? I'm planning to upgrade the app to version 8.0. Will this
solve the saving problem? or are there suggestions as to what type of
programming to avoid when there is a saving problem?

Anonymous

2004-09-23 01:28:32 UTC

Permalink

Thanks for your response.

This app has been altered in the visual atmosphere for the past 6
years. Pretty near all screens were re-done upon conversion. Most
programs were saved. By now, most of the code has been changed enough
to say it's finally a re-write. The tables this app uses are updated
quarterly and are separate from the app as these tables are not
created by me and are far too big for the app to hold within the exe,
so databases haven't been used. I believe 9.0 isn't coming out until
March. We need to address this saving and speed issue sooner. It seems
that 8.0 is more stable in the indexing and table department. Am I
correct?

Post by Rick Bean
I'll assume you mean FPW 2.5/2.6 that ran on Windows 3.1x. How was this
application converted? Did your users upgrade the hardware with the
"new" version - especially memory? With each new version (9.0 will be
out soon!), less and less emphasis has been placed on running the old
xBase code "fast". Consider a rewrite - it's the only way to take
advantage of the newer versions.
Rick

Stefan Wuebbe

2004-09-23 07:54:45 UTC

Permalink

On the other hand, your description does not sound like a
"typical issue" in the first place...

Post by Anonymous
then was converted to FP Visual 6.0, then 7.0. Ever since the initial
conversion to visual, saving data had been a problem, especially
within scans. In order to save properly, I had to resort to a do-while
loop or slow the scan down with 'wait' clauses. This slows the app's
process down considerably and am getting complaints that FoxPro for
windows is faster. What can be done to improve it's speed within
scans/loops? I'm planning to upgrade the app to version 8.0. Will this
solve the saving problem? or are there suggestions as to what type of
programming to avoid when there is a saving problem?

Scan/Endscan usually works just fine in all Fox versions including
the latest and Vfp9 Beta, and is not at all meant for backwards
compatibility only.
You might need to add more details about what's going on in
your code and probably also about your hardware / network
environment, data structures and maintenance approach.
(See also Sys(1104) and Flush in help)

hth
-Stefan

<snipped previous>

Anders Altberg

2004-09-23 09:03:54 UTC

Permalink

Hi Anonymous
Updatable datatables cannot be rolled into an exe. There's no point,
speedwise, ever rolling any data tables into an exe. VFP databases have
nothing to do with this. They are actually separate metadata VFP tables and
not some sort or shell contaniner for tables, like client/server databases.
SCAN is enourmously fast. but SCAN FOR lExpr is only optimzed given
appropriate indexes on the same expression.
You're barking up the wrong tree I'm afraid.
-Anders

Post by Anonymous
Thanks for your response.
This app has been altered in the visual atmosphere for the past 6
years. Pretty near all screens were re-done upon conversion. Most
programs were saved. By now, most of the code has been changed enough
to say it's finally a re-write. The tables this app uses are updated
quarterly and are separate from the app as these tables are not
created by me and are far too big for the app to hold within the exe,
so databases haven't been used. I believe 9.0 isn't coming out until
March. We need to address this saving and speed issue sooner. It seems
that 8.0 is more stable in the indexing and table department. Am I
correct?

Anonymous

2004-09-28 10:26:53 UTC

Permalink

Thanks for your input. I'll check these out.