Hmmm... Good to know. I currently have a system that used to run quite quickly (data lives on network and there are now 7 machines accessing it simultaneously) but it has s-l-o-w-e-d right down recently so I too have been investigating Rushmore Optimisation. The tables have a TON of deleted records now and this gives me one more place to look for speeding it all up.
Sometimes I really think I'd be lost without you ProFox guys - so, thanks. Tina Currie www.datahouse.com.au P.S. 3 weeks to go till I'm not pregnant anymore! (can you guess I don't dig "confinement"?) -----Original Message----- From: Frank Cazabon [mailto:[email protected]] Sent: Wednesday, 16 February 2011 7:39 AM To: [email protected] Subject: Re: Rushmore If you run with SET DELETED ON and don't have an index on DELETED() then you will always get partial optimisation. In order to get full optimisation you'll either have to set DELE OFF or add the index on DELETED(). Do note that this index does not actually guarantee speeding up the query as it depends on the percentage of deleted records in your tables. Frank. Frank Cazabon Samaan Systems Ltd. - Developing Solutions www.SamaanSystems.com Referrals are important to us. If you know of anyone who would benefit from our services, please contact me. We would appreciate the opportunity to work with them. On 15/02/2011 04:32 PM, Sytze de Boer wrote: > My system always starts with SET DELE ON > Is that sufficient ? > S > > > On Wed, Feb 16, 2011 at 9:29 AM, Grigore Dolghin<[email protected]> wrote: > >> Add an index on Deleted(). >> >>> -----Original Message----- >>> From: [email protected] [mailto:profoxtech- >>> [email protected]] On Behalf Of Sytze de Boer >>> Sent: Tuesday, February 15, 2011 10:18 PM >>> To: [email protected] >>> Subject: Rushmore >>> >>> Following up on recent posts where I was trying to determine why a simple >>> sql select was so darned slow .... >>> I've spent a long time on various attempts to speed up the issue >>> >>> I discovered it was really only an issue if the "select * from winhst >> where >>> client=trcask into table tmp " >>> was done where the data was on a network server. >>> I also discovered that my client typically only wanted to "see" the data. >>> My system assumed they now wanted to print copies of invoices, or follow >> it >>> up with reports and the like. >>> >>> So......I now simply "set key to trcask" >>> The result is instant >>> Great outcome (in this instance) >>> >>> But, in the course of all of this, many other issues came up e.g. Mike >>> suggested I take a look at sys(3054) I did and found that no matter what >> I >> do, >>> I can only return a "partial" >>> Rushmore level >>> So I tried the following >>> >>> Use temp exclusive >>> index on client tag temp1 >>> **client is always upper, C(10) >>> set order to 1lcSearch='ABCD' >>> select * from temp where client=lcSearch into cursor tmp >>> >>> The sys(3054) returns a partial optimise only >>> >>> Now I've checked the helpfile and read the Rushmore sections 3 times, and >>> then again by going backwards I'll be darned if I can find why I can >> "only" get >>> partial optimising >>> >>> I need a sleep >>> >>> -- >>> Regards >>> Sytze de Boer >>> Kiss Systems >>> >>> >>> --- StripMime Report -- processed MIME parts --- >>> multipart/alternative >>> text/plain (text body -- kept) >>> text/html >>> --- >>> [excessive quoting removed by server] _______________________________________________ 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.
