I don't have experience with MySQL so I probably would point to that as a likely problem. Like most developers we have

many clients converting to Win7 with no problems at all unlike the nightmare we had with Crapsta.

We have noticed one thing that may be of interest: We have a client with a new Win7 system with 12gb memory. It takes a

long time to load but the client states it is many times faster during data entry and creating reports. My explaination

(with no proof) is that our VFP9 SP2 compiled program is loading all the programs and data into memory. We do open

several data files before the first screen shows. Also, our program does not destroy screens (they are in memory and are

reused) so as you use the program it seems to get faster. Our program and all the initial data would easily fit into 1gb

memory so I can't explain why 12gb would be that much faster than a similar win7 computer with 4gb. It must be something

to do with the operating system and memory management or hardware.

----- Original Message -----

From: "Mike Copeland" <mlcopeland@gmail.com>

To: <profoxtech@leafe.com>

Sent: Wednesday, March 02, 2011 12:02 PM

Subject: Windows 7 + VFP9 speed problem

It's been a while since I've been on the list, but I've run into a real

buzz-saw of a VFP problem, thanks in part to Windows 7. I'd really be

appreciative of any and all thoughts on this issue as I'm stumped.

Application: A monolithic accounting application with a few dozen forms.

Compiled exe is 6MB

Platform: Win XP or Win 7 (32 or 64 bit) plus VFP 9 SP2 and MySQL

Add to the mix: DBI Technologies ctGrid OCX file (although I don't think

this is the source of the problem)

Hardware: Not relevant, but 4GB RAM, Dual Core 3Ghz Intel CPU on Intel

G31 Mboard

Problem: When loading a form, depending on the platform, it can take

160x as long to finish.

Task: Load 23,000 SKU #s into a combo. (details below)

Times below are very very consistent, varying only about .10 second each

run.

Scenario 1: Windows XP, compiled VFP exe application, all files local

(except MySQL data)

FAST....as in 1/2 second

Scenario 2: Windows XP, run app from source code on VFP IDE, all files

local

FAST...again, around 1/2 second

Scenario 3: Windows 7 (32 or 64 bit), source code on VFP IDE, all files

local

FAST...1/2 second

...here's the problem

Scenario 4: Windows 7, compiled exe app, all files local

SLOW....80 seconds

This happens on multiple forms that have almost

identical code.

...here's the head banger

Scenario 5: Windows 7, running compiled exe from a Linux Samba share

FAST....actually a bit faster than running on

Windows XP...less than 1/2 seconds

Windows 7 is becoming unavoidable. The solution seems to be to run the

app from the server, but many details (storage of window sizes, auto

update to new version, etc.) have been designed for local workstation

storage.

What I can not understand is why Scenario 4 is so radically different.

Any suggestions?

What I've tried:

1. Turned off UAC completely. (Started with UAC on, of course.) No effect.

2. Change ownership of the folder the files are stored in. No effect.

3. Installed full VFP IDE, removed, installed VFP9 SP2 run-time only

files No effect, although I was surprised at how fast it was (Scenario 3

above)

4. Introduced delays into code loop...i.e., DOEVENTS and "wait window ''

nowait"

5. Tried saving SELECTED data in a local DBF and loading from DBF. (This

did tweak the timing a little, like 4 seconds out of 80) Even tried

saving static data in DBF and not even involving the MySQL process.

6. Created single form with nothing but the DBI grid OCX object and

compiled as a 48Kb application. This ran fast, 1/2 second to load, but

while informative it is hardly useful.

7. I've tested and tried placing the TMPFILES location local and remote,

and let Windows manage it vs. "manual override." No change.

All in all, it seems to be pointing at a problem with the interaction

between Windows 7 and VFP9 SP2 and memory management.

I'm sure I've missed something, and I know this is a lot to read, but I

would very much appreciate any suggestions. I know of no better place to

go than here where the best and the brightest connect.

Oh, here's the code from the INIT event on the form (I've tried various

other events, and even put it in the click event of a button on the

form, no change)

Also, you'll notice there's no indication of how I'm getting the data

from MySQL. The sample below has the same speed issues described above,

but as you can see the retrieval from the MySQL server is not involved

in the timing and is actually very fast in all scenarios.

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

MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')

LOCAL ttimestart,ttimeexp

SELECT sku FROM skus into temp WHERE active=1 order by sku

SELECT temp

GO TOP IN temp

ttimestart=seconds()

SCAN WHILE !EOF('temp')

thisform.ctGrid.addcomboitem(1,temp.sku)

ENDSCAN

ttimeexp=seconds()-ttimestart

MESSAGEBOX('Finished.'+CHR(13)+ALLTRIM(STR(RECCOUNT('temp')))+' items added.'+;

CHR(13)+'Time elapsed: '+ALLTRIM(STR(ttimeexp,6,2))+' seconds',0+64,'Notice')

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

Thanks again!

Mike Copeland

[excessive quoting removed by server]

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://leafe.com/mailman/listinfo/profox

OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/0d3e01cbd9b4$9a810b00$7a00a8c0@w2k3s02

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.