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: 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/4D6EA26C.5060905@ggisoft.com
** 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.
Try using the coverage profiler. It will tell you everyline of source that
is executed and the amount of time it takes for each line.
Set coverage to test.log
Set coverage on
-----Original Message-----
From: profox-bounces@leafe.com [mailto:profox-bounces@leafe.com] On Behalf
Of Mike Copeland
Sent: Wednesday, March 02, 2011 3:03 PM
To: profoxtech@leafe.com
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/7C49B4B783814045BA4C249063487A68@LaptopW7
** 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.
Could be an SMB2 issue? Search the Profox archives and look for SMB2. There might be some useful info from these threads on ProFox:
Re: Strange Data Corruption Issue
Re: Any gurus out there?
--
rk
-----Original Message-----
From: profoxtech-bounces@leafe.com [mailto:profoxtech-bounces@leafe.com] On Behalf Of Mike Copeland
Sent: Wednesday, March 02, 2011 3:03 PM
To: profoxtech@leafe.com
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/DF1EEF11E586A64FB54A97F22A8BD0441922355B26@ACKBWDDQH1.artfact.local
** 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.
Author: MB Software Solutions, LLC
Posted: 2011-03-03 08:52:46 Link
On 3/2/2011 3:02 PM, Mike Copeland wrote:
<snipped>
> 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
Mike,
Slight tweaks:
> MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
> LOCAL ttimestart,ttimeexp
> SELECT sku FROM skus into CURSOR temp WHERE active=1 order by sku
> SELECT temp
> LOCATE
>
> ttimestart=seconds()
>
> SCAN
> thisform.ctGrid.addcomboitem(1,temp.sku)
> ENDSCAN
Not sure if that'll make much difference, but it's known that LOCATE is
quicker than GO TOP. Also, your SCAN loop doesn't need the WHILE !EOF
clause.
My comment on the design is that I wouldn't do 23,000 items in a combo,
but I guess you can't change that now?
--
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
_______________________________________________
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/4D6F9D2E.70803@mbsoftwaresolutions.com
** 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.
Mike Copeland wrote on 2011-03-02:
<snip>
> 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')
---------------------------------------------------------------------- -
Mike,
Move the code to a new method on the form. Then call it from the
ctGrid.FirstDraw event.
See if turning off the fancy Windows 7 graphical themes with SYS(2700,0).
Tracy Pearson
PowerChurch Software
_______________________________________________
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/000001cbd9b1$23333b70$6999b250$@com
** 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.
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.
Mike
I deal with a large VFP9 application that is installed on thousands of
sites, and we are seeing occurrences of this also, to the extent where a
customer will bring in a new Windows 7 machine and it will be extremely
slow, with the other 5-year-old XP machines on the network being fast at
the same operations.
This application has EXE and supporting files locally on the clients,
accessing data on a server share.
My suspicion is that this is due to the different network stack in
Windows 7, crappy Windows 7 drivers for network cards, differences in
the way it negotiates with network hardware, or a combination of these.
I don't have one of these problem sites near me to investigate at the
minute unfortunately.
If you have a Windows Server 2008 in the mix you definitely need to
either set the server to use SMB1 over SMB2, or alternatively apply the
SMB2 hotfix that MS released recently. This will stop index corruption
issues at the very least.
There is also talk that turning off Remote Differential Compression may
help, see here:
http://serverfault.com/questions/85965/slow-network-file-copy-on-windows-7
--
Alan Bourke
alanpbourke (at) fastmail (dot) fm
_______________________________________________
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/1299166158.8356.1425826393@webmail.messagingengine.com
** 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.
On Thu, Mar 3, 2011 at 3:29 PM, Alan Bourke <alanpbourke@fastmail.fm> wrote:
> If you have a Windows Server 2008 in the mix you definitely need to
> either set the server to use SMB1 over SMB2, or alternatively apply the
> SMB2 hotfix that MS released recently. This will stop index corruption
> issues at the very least.
This is supposibly fixed in Windows 7 SP1. Can anyone confirm?
I'm waiting for this to come over my WSUS update server, but it looks
like MicroSoft haven't released it to this channel yet.
--
Paul
_______________________________________________
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/AANLkTik31cvew7Xb-Y_fEscrd9QnrSrZjNR2HQr26vDv@mail.gmail.com
** 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.
kamcginnis@gmail.com wrote on 2011-03-03:
> 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.
>
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work in
VFP 9 at all
Tracy Pearson
PowerChurch Software
_______________________________________________
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/000801cbd9bb$7bf49790$73ddc6b0$@com
** 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.
Author: MB Software Solutions, LLC
Posted: 2011-03-03 12:32:35 Link
On 3/3/2011 10:55 AM, Tracy Pearson wrote:
> I wonder if this much memory ends up swapping.
> This might be a good reason to change the SYS(3050) settings.
> Perhaps your Config.fpw might need the old MEMLIMIT, which may not work in
> VFP 9 at all
Use Ed Leafe's Setmemory.prg. It's in the Downloads section on ProFox.
--
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
_______________________________________________
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/4D6FD0B3.7010601@mbsoftwaresolutions.com
** 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.