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
_______________________________________________
Post Messages to: [email protected]
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/[email protected]
** 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.
