Tracy,
that's the old OpLocks settings, not sure if they are relevant in Win 10
and Server 2008 (I haven't used DBFs in a long time).
Mike, I can provide the registry settings that you need to fiddle with
if that is the problem.
Frank.
Frank Cazabon
On 01/12/2017 08:10 AM, Tracy Pearson wrote:
I had a question about how a statement could get slow response times in the
past. Christof gave a long explanation about client and server cache. One
person connected to the table the program is fast. Get a second person and the
program gets real slow. I'll try to search for it later.
Tracy
On November 30, 2017 10:54:38 PM EST,
mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
Client's app performance is dreadfully slow, and I believe the Server
is
largely responsible. Dealing with a former PITA Corporate tech support
team who doesn't know jack squat about VFP and is telling me how it
works, especially on the application that I worked on from 2007 to 2010
and was never updated after I left. They probably can't even spell
FoxPro. VFP9SP1 application running on client's workstation, using VFP
free tables on network share folder managed by Stonefield Database
Toolkit. Workstations are Win10 Pro. Server is Windows 2008 Standard.
On the server, they've got Windows Defender *AND* an outdated Symantec
Endpoint on there that hasn't been updated since 2015
(https://www.screencast.com/t/n5dYLWF0). I also wanted them to add the
relevant VFP exclusions in Windows Defender. They said they were
there,
and I showed here "no they're not."
(https://www.screencast.com/t/6vioItlZSuu9)
Corporate "engineering" said this, regarding the slowness: "It's a
32-bit OS so it can only utilize 4GB of RAM. Sym_data folder is almost
600MB, with the most common used features being the largest. The files
are locked, transferred over the network and then updated and written
back."
It's the last part especially that has me fueled up to deliver a smack
down. Here's what my Draft reply is to my former coworker Tim, who is
the Tech who sent me the bullshit answer:
************************
As for this comment (and I'm sure you copied it from the Engineering
folks, so I'm not saying that YOU TIM are incorrect): "It's a 32-bit
OS
so it can only utilize 4GB of RAM. Sym_data folder is almost 600MB,
with the most common used features being the largest. The files are
locked, transferred over the network and then updated and written
back."
-- Tim, the OS has nothing to do with it; 32-bit is fine, and
Symplicity won't utilize that much RAM anyway. More important that
needs correcting is this Engineering person's understanding of how the
Symplicity application and database work; his/her comments about the
entire 600MB of files being locked, transferred over the network, then
updated and written back are wrong. The Symplicity application is a
Visual FoxPro 9.0 SP2 application that uses a File Server database and
unlike Access or some other types like that, it does NOT suck over the
entire dataset but instead takes the CDX files (which are the index
files) to read the relevant data from the network DBFs, only dealing
with data requested in the application as needed. Trust me, I know
what
I'm talking about as you know I fixed the Symplicity application's
major
bugs from 2007 to 2010, something perhaps your Engineering folks don't
know. And it was never updated after I released version 4.0 before I
left in 2010. Nobody at your company before or now knows as much about
that application and its abilities as I do. That's not arrogance;
that's an obvious fact.
************************
So...I am right that the entire 600MB of VFP data files on the network
share don't come down over the network, but instead the indexes do,
right? I don't even think the DBF comes down--all the "locking" occurs
on the file server. I'm betting heavily on this one. Am I right? Was
my Access comment right?
(Ok, maybe I was a bit arrogant there, but these dudes need to
seriously
be corrected.)
tia!
--Mike
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/dc940479-1a00-2db5-a5e3-323588d0d...@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.
