Mike,
You are 100% Correct and in fact the indexes aren't always downloaded in their
entirety if Rushmore takes effect as only the major Leaf Nodes need to be
interrogated for fully optimised searches.
The DBF header comes down and is locked briefly before being written back for
obvious reasons to update the DBF record counts etc. but that is a minor data
transfer.
Personally I'd get them to check that the file caching is turned OFF on the
server as the default value was to have it turned on in 2008: Device
manager/Disk/Properties.
Obviously high tech numpties who think they know it all but actually understand
very little!
Dave
---------------------------------------------------------------
This communication and the information it contains is intended for the person
or organisation to whom it is addressed. Its contents are confidential and may
be protected in law. If you have received this e-mail in error you must not
copy, distribute or take any action in reliance on it. Unauthorised use,
copying or disclosure of any of it may be unlawful. If you have received this
message in error, please notify us immediately by telephone or email.
Flexipol Packaging Ltd. has taken every reasonable precaution to minimise the
risk of virus transmission through email and therefore any files sent via
e-mail will have been checked for known viruses. However, you are advised to
run your own virus check before opening any
attachments received as Flexipol Packaging Ltd will not in any event accept any
liability whatsoever once an e-mail and/or any attachment is received.
It is the responsibility of the recipient to ensure that they have adequate
virus protection.
Flexipol Packaging Ltd.
Unit 14 Bentwood Road
Carrs
Industrial Estate
Haslingden
Rossendale
Lancashire
BB4 5HH
Tel:01706-222792
Fax: 01706-224683
www.Flexipol.co.uk
---------------------------------------------------------------
Terms & Conditions:
Notwithstanding delivery and the passing of risk in the goods, the property in
the goods shall not pass to the buyer until the seller
Flexipol Packaging Ltd. ("The Company") has received in cash or cleared funds
payment in full of the price of the goods and all other goods agreed to be sold
by the seller to the buyer for which payment is then due. Until such time as
the property in the goods passes to the buyer, the buyer shall hold the goods
as the seller's fiduciary agent and bailee and keep the goods separate from
those of the buyer and third parties and properly stored protected and insured
and identified as the seller's property but shall be entitled to resell or use
the goods in the ordinary course of its business. Until such time as the
property in the goods passes to the buyer the seller shall be entitled at any
time
-----Original Message-----
From: ProFox [mailto:[email protected]] On Behalf Of
[email protected]
Sent: 01 December 2017 03:55
To: ProFox <[email protected]>
Subject: Check my wording on this and tell me if I'm right
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
_______________________________________________
Post Messages to: [email protected]
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/[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.
_______________________________________________
Post Messages to: [email protected]
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/[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.
