Re: CONTAINS performance
From: John Kane (jt-kane_at_comcast.net)
Date: 10/27/04
- Next message: John Kane: "Re: OLE DB provider 'MSIDXS' reported an error. Access denied."
- Previous message: John Kane: "Re: CONTAINS performance"
- In reply to: malcolm.earnest_at_bom.co.uk: "Re: CONTAINS performance"
- Next in thread: malcolm.earnest_at_bom.co.uk: "Re: CONTAINS performance"
- Reply: malcolm.earnest_at_bom.co.uk: "Re: CONTAINS performance"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 27 Oct 2004 09:23:55 -0700
You're welcome, Mal,
In terms of scalability, the best metric is the total number of rows in each
of your tables. Could you post the count(*) for each of your tables? SQL
Server 2000 Full-Text Search (FTS) was only tested up to 20 million rows and
while it can scale up to many millions of rows, at or above the million row
mark, FTS needs to be very carefully tuned to achieve second response times,
see SQL Server 2000 BOL title "Full-text Search Recommendations" for more
info on this.
When you include the "TOP 100" in your query, you are in fact limiting the
"end result" and not the "full scan" of the FT Catalog that is being scanned
three times, once for each of your CONTAINS clauses, in affect the TOP 100
has no affect on the FT Catalogs and if they are large, then this query will
take a long time to execute. What is a better solution in addition to
eliminating the number of CONTAINS, is to use CONTAINSTABLE and Top_N_Rank
as this fix (for SQL Server 7.0) is included in SQL Sever 2000 and does in
fact limit the "full scan" to just the Top (N or number) by RANK. See KB
article 240833 (Q240833) "FIX: Full-Text Search Performance Improved via
Support for TOP" at
http://support.microsoft.com//default.aspx?scid=kb;EN-US;240833 for more
information. Note, you can combine TOP in the select list with Top_N_Rank,
but you need to be careful with the values you use and I would recommend for
performance reasons, that you set the Top_N_Rank to no more than 2000 as
this is a "magic number" for the MSSearch service in returning data to SQL
Server.
I am glad that you have noted that changing the tables is not possible as
they are "set-in-stone" and I should emphasis that many of your points are
valid for SQL queries, they often do not apply to FTS queries because the FT
data structure are maintained outside of SQL Sever (usually under the
\FTDATA directory) by the MSSearch service. Specifically, the terminology
"scans of the FTS catalogs" relates to the "full scan" or as it is sometimes
called in this newsgroup a full "round trip" to the FT Catalog for each FTS
predicate (contains* or freetext*). Much of are assumptions related to
"scans of the FTS catalogs" is conjecture as the query plans for FTS queries
only provide limited information on the "remote" or FT Catalog scan.
Mal, I understand your simplification of not only the table names
(confidentiality, etc), but also your reluctance for a more detailed
sp_help, but understand FTS issues is a bit more complex as both the
datatype (text, char, varchar vs. IMAGE) is important as well as the actual
data (punctuation characters in contact with the search words, language of
the text, the actual file types stored, etc) as well as the OS platform as
the latter supplies the wordbreaker and can return or not return the
expected results. So, asking for this kind of information up front before
making assumptions is a crucial aspect of troubleshooting and making
recommendations for these types of FTS queries. Could you provide the full
output of -- SELECT @@version -- as this too is helpful in understanding
your environment!
The stored procedure was simply an example of provide you with a "simple"
alternative to think about while we waited for your reply and it does seem
that you have thought about it! I've attached a more complex SQL script
(Containstable_mutiple_tables.sql) that does use three tables (ItemStock,
ItemTitles & ItemHardware) all with a common PK & FK relationship, the
original problem query, test data via INSERTs from a past issue that was
related to a common word queried from all three tables. You may alter this
SQL script and add data and alter your query to fit these tables and data
and then we can work with real data without compromising your
confidentiality issues.
Yes, the "Best Practices Analyzer Tool" is a full supported Microsoft SQL
Server tool and can be downloaded at:
http://www.microsoft.com/downloads/details.aspx?FamilyID=b352eb1f-d3ca-44ee-893e-9e07339c1f22&displaylang=en
A long answer to a long reply, but hopefully with the attached SQL script
and without making assumptions we can help you!
Thanks,
John
"Mal Earnest" <malcolm.earnest@bom.co.uk> wrote in message
news:eaIxnnBvEHA.2016@TK2MSFTNGP15.phx.gbl...
> First and foremost, John and Hillary thank you both for your responses...
I've not established what I set out to discover as yet, but there were
several useful ideas, and you both asked me to clarify my question.
>
> When I initially asked about performance - I suppose I should have made it
clearer that I am primarily concerned by scalability. I can put-up with the
wall-clock speed of execution at present but I need to establish that as the
number of records grows over time that my solution won't grind to a halt.
>
> The advice to limit the number of results was good - I'd omitted that for
brevity - the actual form of query which interests me includes such a
limit - I'd have better stated the query:
>
> Select top 100 * from
> A left outer join B on A.bid=B.id
> left outer join C on A.cid=C.id
> Where
> contains(A.*, 'word')
> or contains (B.*, 'word')
> or contains (C.*, 'word')
>
> Assume that the 'word' I choose to search upon is sufficiently unusual to
limit my result-set after application of the where clause to between, say, 0
and 10 rows and that all these rows must be returned to my client - hence
for the circumstances I was considering the TOP 100 would likely have no
significant effect on performance. As you might have guessed, the query I
posted is a significant simplification of a series of real world problems
(hence the generic names) the detailed explanation of which is way beyond
the scope of a post here. In my example the relationship from A to B and
from A to C is 1..n. For some of the tables I actually use B.id is unique in
B; in some C.id unique in C; for some both are unique; for some neither.
Many queries and updates within the system only act upon these tables
individually (hence fixing the table structure.) I also require support for
data mining searches for which the result set matches that returned for the
query above. While I can see a potential for improving performance by using
a simplified table structure (and avoiding the complexity of evaluation
strategy introduced by left-outer-join) this is not practical as a
consequence of other binding project constraints. I need to keep the
distinct tables I introduced as A, B and C - their relationship can be
considered "set-in-stone." I realise that a single table would eliminate
concerns about performance but that idea is not an option for this project.
>
> I'm still a little unclear about your terminology (specifically "scans of
the FTS catalogs" and "table scans") I suspect that this relate closely to
what I consider the primary performance concern.
>
> I assume by "table scans" you suggest that SQLServer might evaluate both
outer joins for each record in A then establish if the candidate result rows
match any of the three contains clauses? If this is the case then the
performance would be worse than linear in the number of records in A - and
hence exhibit relatively poor scalability.
>
> I assume "scans of the FTS catalogs" you mean that SQLServer might use the
text index to efficiently establish rows from A matching the contains
predicate ranging over A; outer join those rows with B and C to get the
initial result rows; establish in B using the text index rows matching the
contains predicate ranging over B then inner join those results with A, then
outer join that result with C; finally use the text index for C to
efficiently establish the remaining rows in C before inner joining those
with A and outer joining with B - all the while carefully arranging not to
return the exact same row twice? This would be a workable strategy but it
feels 'unlikely' as it both fails to explain observed performances during my
(extremely limited and potentially very error prone) experiments and because
when I specified two OUTER JOIN expressions in my query I wouldn't have
expected the optimiser to implement this using two inner-join and four
outer-join relationships unless I re-write my query to explicitly hint that
this is the way I need the query to be evaluated. While this approach to
establish the result set is relatively complex, it offers far better
scalability - especially if table A happens to have a large number of
records.
>
> I'm not in a position to give concrete sp_help output - primarily as this
question is a massive simplification of the actual queries I use... Tables
typically have 20-50 fields of various types (CLOB; BLOB; integer; date;
etc. etc.); All tables have an integer primary key and in example above
assume indices are defined on B.id and C.id - each of which is can be
assumed ordinal (say integer). The textual information is free-text enabled
in every table.
>
> I didn't understand John's stored procedure - but the idea of a stored
procedure to make explicit an evaluation strategy for the desired result-set
is certainly an interesting and technically plausible possibility... all be
it one which would prove quite a challenge in the context of my project!
>
> I'm not encountered the "Best Practices Analyzer Tool" - though the advice
on http://www.sqldude.4t.com/rules.html looks familiar enough. Is this tool
supplied with SQLServer or is it 3rd party product? Would this tool tell me
how my query is being optimised?
>
> At this stage I'm trying to establish if my hunch is accurate about the
scalability of queries of the type illustrated above. I am aware that the
three contains clauses would be detrimental to performance - and I am aware
that if I had a single flat table that any performance issues would likely
disappear. I'm also aware that I could use an alternative sequence of
queries to efficiently establish the same result rows - but it would be a
big task to re-write my query generator to make this optimisation and I am
reluctant to do this if there is an alternative. Queries of the form above
work OK for my current test data on a quick server - (hundreds of records)
but I want a solution which will scale to support hundreds of thousands to
millions of records. I'm still not clear how the query above will be
optimised - and, as such, I'm still not in a position to estimate
scalability. I can't use a single table and avoid outer-joins - but I might
be able to alter the way in which the tables are indexed if that would
influence the optimiser in a positive way.
>
> **********************************************************************
> Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
> Comprehensive, categorised, searchable collection of links to ASP &
ASP.NET resources...
begin 666 Containstable_mutiple_tables.sql
M#0HM+0EF:6QE;F%M93H@0V]N=&%I;G-T86)L95]M=71I<&QE7W1A8FQE<RYS
M<6P-"BTM"7!U<G!O<V4Z('1O(&1O8W5M96YT(&AO=R!T;R!U<V4@8V]N=&%I
M;G-T86)L92!A;F0@9G)E971E>'1T86)L92!I;B!M=71I<&QE($944R!Q=65R
M:65S#0HM+0EM;V1I9FEE9#H@,3 Z,#4@4$T@-R\Q,B\R,# T#0H-"G5S92!S
M<6QF=',-"F=O#0IS96QE8W0@0$!V97)S:6]N("TM($UI8W)O<V]F="!344P@
M4V5R=F5R(" R,# P("T@."XP,"XW-C @;VX@16YT97)P<FES92!%9&ET:6]N
M(&]N(%=I;F1O=W,@3E0@-2XR("A"=6EL9" S-SDP.B I#0HO*@T*+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM#0I-:6-R
M;W-O9G0@4U%,(%-E<G9E<B @,C P," M(#@N,# N-S8P("A);G1E;"!8.#8I
M("T@1&5V96QO<&5R($5D:71I;VX@;VX@5VEN9&]W<R!.5" U+C$@*$)U:6QD
M(#(V,# Z(%-E<G9I8V4@4&%C:R Q*0T*4$LO1DL@<F5L871I;VYS:&EP(&)E
M='=E96X@271E;5-T;V-K+D]R9&5R3F\@/2!)=&5M5&ET;&5S+D]R9&5R3F\@
M86YD(&%L<V\@271E;5-T;V-K+D]R9&5R3F\@/2!)=&5M2&%R9'=A<F4N3W)D
M97).;RX@#0HJ+PT*#0HM+2!$969I;F4@=&%B;&5S+BXN#0I#4D5!5$4@5$%"
M3$4@6V1B;UTN6TET96U3=&]C:UT@* T*(%M/<F1E<DYO72!;=F%R8VAA<ET@
M*#4P*2!#3TQ,051%(%-13%],871I;C%?1V5N97)A;%]#4#%?0TE?05,@3D]4
M($Y53$P@+" M+2!02R!)=&5M4W1O8VL@+2!U;FEQ=64@/PT*(%M,86)E;%T@
M6W9A<F-H87)=("@U,"D@0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q
M7T-)7T%3($Y/5"!.54Q,("P-"B!;4V]F=$AA<F1=(%MV87)C:&%R72 H-3 I
M($-/3$Q!5$4@4U%,7TQA=&EN,5]'96YE<F%L7T-0,5]#25]!4R!.54Q,("P-
M"B!;36%N0V]D95T@6W9A<F-H87)=("@U,"D@0T],3$%412!344Q?3&%T:6XQ
M7T=E;F5R86Q?0U Q7T-)7T%3($Y53$P@+ T*(%M$97-C<FEP=&EO;ET@6W9A
M<F-H87)=("@U,"D@0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)
M7T%3($Y53$P@+ T*(%MD7U5P9&%T95T@6V1A=&5T:6UE72!.54Q,("P-"B!;
M17AC;'5S:79E72!;=F%R8VAA<ET@*#4P*2!#3TQ,051%(%-13%],871I;C%?
M1V5N97)A;%]#4#%?0TE?05,@3E5,3" L#0H@6T%F9FEL:6%T95T@6W9A<F-H
M87)=("@U,"D@0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)7T%3
M($Y53$P@+ T*(%M.97=296QE87-E72!;=F%R8VAA<ET@*#4P*2!#3TQ,051%
M(%-13%],871I;C%?1V5N97)A;%]#4#%?0TE?05,@3E5,3" L#0H@6U-T871U
M<UT@6W9A<F-H87)=("@U,"D@0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?
M0U Q7T-)7T%3($Y53$P@+ T*(%M);G9=(%MD96-I;6%L72@U+" P*2!.54Q,
M("P-"B!;9%]$871E72!;9&%T971I;65=($Y53$P@+ T*(%M#871E9V]R>5T@
M6W9A<F-H87)=("@U,"D@0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q
M7T-)7T%3($Y53$P@+ T*(%M3:6YG;&5!<G1I<W1=(%MV87)C:&%R72 H,RD@
M0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)7T%3($Y53$P@+ T*
M(%MS7U1Y<&5=(%MV87)C:&%R72 H-3 I($-/3$Q!5$4@4U%,7TQA=&EN,5]'
M96YE<F%L7T-0,5]#25]!4R!.54Q,("P-"B!;5'EP941E<V-R:7!=(%MV87)C
M:&%R72 H,3 P*2!#3TQ,051%(%-13%],871I;C%?1V5N97)A;%]#4#%?0TE?
M05,@3E5,3" L#0H@6T-A<V5D72!;=F%R8VAA<ET@*#4P*2!#3TQ,051%(%-1
M3%],871I;C%?1V5N97)A;%]#4#%?0TE?05,@3E5,3" L#0H@6U!A8VME9%T@
M6W9A<F-H87)=("@U,"D@0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q
M7T-)7T%3($Y53$P@+ T*(%M-86YU9ET@6W9A<F-H87)=("@U,"D@0T],3$%4
M12!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)7T%3($Y53$P@+ T*(%M-86Y3
M;W)T72!;:6YT72!.54Q,("P-"B!;5V5I9VAT72!;9&5C:6UA;%TH-2P@,BD@
M3E5,3" L#0H@6TEC;VYS-S5=(%MV87)C:&%R72 H,3 P*2!#3TQ,051%(%-1
M3%],871I;C%?1V5N97)A;%]#4#%?0TE?05,@3E5,3" L#0H@6TEC;VYS,3 P
M72!;=F%R8VAA<ET@*#$P,"D@0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?
M0U Q7T-)7T%3($Y53$P@+ T*(%M)8V]N<S(P,%T@6W9A<F-H87)=("@Q,# I
M($-/3$Q!5$4@4U%,7TQA=&EN,5]'96YE<F%L7T-0,5]#25]!4R!.54Q,("P-
M"B!;26-O;G,S,#!=(%MV87)C:&%R72 H,3 P*2!#3TQ,051%(%-13%],871I
M;C%?1V5N97)A;%]#4#%?0TE?05,@3E5,3" L#0H@6TE$72!;;G5M97)I8UTH
M,3 L(# I($E$14Y42519("@Q+" Q*2!.3U0@3E5,3" M+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM/B!O<B!02R _(&IU<W0@9F]R($94($EN9&5X(#\-
M"BD@3TX@6U!224U!4EE=#0I'3PT*04Q415(@5$%"3$4@271E;5-T;V-K(%=)
M5$@@3D]#2$5#2R!!1$0@4%))34%262!+15D@0TQ54U1%4D5$("A/<F1E<DYO
M*0T*9V\-"BTM($EN<V5R="!T97-T('-A;7!L92!D871A#0II;G-E<G0@:6YT
M;R!)=&5M4W1O8VL@=F%L=65S("@G,# P,2<L("=4:&ES(&ES($QA8F5L(# P
M,#$@;V8@<F]W(&]N92!":6QL>2!*;V5L)RQ.54Q,+$Y53$PL3E5,3"Q.54Q,
M+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,
M+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,
M+$Y53$PI#0II;G-E<G0@:6YT;R!)=&5M4W1O8VL@=F%L=65S("@G,# P,B<L
M("=4:&ES(&ES($QA8F5L(# P,#(@;V8@<F]W('1W;R!3=&EN9R<L3E5,3"Q.
M54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.
M54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.
M54Q,+$Y53$PL3E5,3"Q.54Q,*0T*:6YS97)T(&EN=&\@271E;5-T;V-K('9A
M;'5E<R H)S P,#,G+" G5&AI<R!I<R!,86)E;" P,# S(&]F(')O=R!T:')E
M92!344P@4V5R=F5R)RQ.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.
M54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.
M54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PI#0II;G-E
M<G0@:6YT;R!)=&5M4W1O8VL@=F%L=65S("@G,# P-"<L("=4:&ES(&ES($QA
M8F5L(# P,#0@;V8@<F]W(&9O=7(@3U)!0TQ%)RQ.54Q,+$Y53$PL3E5,3"Q.
M54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.
M54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.
M54Q,+$Y53$PI#0HM+2!R;W<@3D]4(&EN($ET96U4:71L97,L(&)U="!I<R!I
M;B!)=&5M2&%R9'=A<F4-"FEN<V5R="!I;G1O($ET96U3=&]C:R!V86QU97,@
M*"<P,# U)RP@)U1H:7,@:7,@3&%B96P@,# P-2!O9B!R;W<@9FEV92!);G1E
M<F9A8V4G+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,
M3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,
M3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"D-"F=O#0H-"D-214%4
M12!404),12!;9&)O72Y;271E;51I=&QE<UT@* T*(%M/<F1E<DYO72!;=F%R
M8VAA<ET@*#4P*2!#3TQ,051%(%-13%],871I;C%?1V5N97)A;%]#4#%?0TE?
M05,@3D]4($Y53$P@+ T*(%M4:71L95T@6W9A<F-H87)=("@W,"D@0T],3$%4
M12!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)7T%3($Y/5"!.54Q,("P-"B!;
M07)T:7-T72!;=F%R8VAA<ET@*#8P*2!#3TQ,051%(%-13%],871I;C%?1V5N
M97)A;%]#4#%?0TE?05,@3D]4($Y53$P@+ T*(%M,;V-A=&EO;ET@6W9A<F-H
M87)=("@U,"D@0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)7T%3
M($Y/5"!.54Q,("P-"B!;4V]R=$ME>5T@6V1E8VEM86Q=*#4L(# I($Y/5"!.
M54Q,("P-"B!;1&ES8U])1%T@6W9A<F-H87)=("@U,"D@0T],3$%412!344Q?
M3&%T:6XQ7T=E;F5R86Q?0U Q7T-)7T%3($Y53$P@+ T*(%M-4#-&:6QE<UT@
M6W9A<F-H87)=("@Q,# I($-/3$Q!5$4@4U%,7TQA=&EN,5]'96YE<F%L7T-0
M,5]#25]!4R!.54Q,("P-"B!;241=(%MN=6UE<FEC72@Q,"P@,"D@241%3E1)
M5%D@*#$L(#$I($Y/5"!.54Q,#0HI($].(%M04DE-05)970T*1T\-"D%,5$52
M(%1!0DQ%($ET96U4:71L97,@5TE42"!.3T-(14-+($%$1"!04DE-05)9($M%
M62!#3%535$52140@*$]R9&5R3F\I#0IG;PT*+2T@26YS97)T('1E<W0@<V%M
M<&QE(&1A=&$-"FEN<V5R="!I;G1O($ET96U4:71L97,@=F%L=65S("@G,# P
M,2<L)U1H:7,@:7,@5&ET;&4@,# P,2!O9B!R;W<@;VYE(%-T<F%N9V5R)RPG
M0FEL;'D@2F]E;"<L)R!3;VUE<&QA8V4@:&5R92<L,2Q.54Q,+$Y53$PI#0II
M;G-E<G0@:6YT;R!)=&5M5&ET;&5S('9A;'5E<R H)S P,#(G+"=4:&ES(&ES
M(%1I=&QE(# P,#(@;V8@<F]W('1W;R!3=&EN9R<L)U-T:6YG)RPG(%-O;65P
M;&%C92!T:&5R92<L.2Q.54Q,+$Y53$PI#0II;G-E<G0@:6YT;R!)=&5M5&ET
M;&5S('9A;'5E<R H)S P,#,G+"=4:&ES(&ES(%1I=&QE(# P,#,@;V8@<F]W
M('1H<F5E(%-13"!397)V97(G+"=-:6-R;W-O9G0G+"<@4V]M97!L86-E(&5L
M<V4G+#@L3E5,3"Q.54Q,*0T*:6YS97)T(&EN=&\@271E;51I=&QE<R!V86QU
M97,@*"<P,# T)RPG5&AI<R!I<R!4:71L92 P,# T(&]F(')O=R!F;W5R($]2
M04-,12<L)T]R86-L92<L)R!3;VUE<&QA8V4@96QS92<L-"Q.54Q,+$Y53$PI
M#0IG;PT*#0HM+2!)=&5M4W1O8VLN3W)D97).;R ]($ET96U(87)D=V%R92Y/
M<F1E<DYO+B -"D-214%412!404),12!;9&)O72Y;271E;4AA<F1W87)E72 H
M#0H@6T]R9&5R3F]=(%MV87)C:&%R72 H-3 I($-/3$Q!5$4@4U%,7TQA=&EN
M,5]'96YE<F%L7T-0,5]#25]!4R!.3U0@3E5,3" L#0H@6W-?<&%G95T@6W9A
M<F-H87)=("@V,"D@0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)
M7T%3($Y53$P@+ T*(%MS7U1H=6UB72!;=F%R8VAA<ET@*#$U,"D@0T],3$%4
M12!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)7T%3($Y53$P@+ T*(%MS7W!I
M8UT@6W9A<F-H87)=("@Q-3 I($-/3$Q!5$4@4U%,7TQA=&EN,5]'96YE<F%L
M7T-0,5]#25]!4R!.54Q,("P-"B!;4$1&4V-A;&5=(%MV87)C:&%R72 H-3 I
M($-/3$Q!5$4@4U%,7TQA=&EN,5]'96YE<F%L7T-0,5]#25]!4R!.54Q,("P-
M"B!;;5]3<&5C<UT@6W9A<F-H87)=("@X,# P*2!#3TQ,051%(%-13%],871I
M;C%?1V5N97)A;%]#4#%?0TE?05,@3E5,3" L#0H@6U!$1E-P96-S72!;=F%R
M8VAA<ET@*#@P,# I($-/3$Q!5$4@4U%,7TQA=&EN,5]'96YE<F%L7T-0,5]#
M25]!4R!.54Q,("P-"B!;3F]T97-=(%MV87)C:&%R72 H.# P,"D@0T],3$%4
M12!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)7T%3($Y53$P@+ T*(%M-961I
M85T@6W9A<F-H87)=("@S*2!#3TQ,051%(%-13%],871I;C%?1V5N97)A;%]#
M4#%?0TE?05,@3E5,3" L#0H@6T-A<W-=(%MV87)C:&%R72 H,RD@0T],3$%4
M12!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)7T%3($Y53$P@+ T*(%M#1$==
M(%MV87)C:&%R72 H,RD@0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q
M7T-)7T%3($Y53$P@+ T*(%M60T1=(%MV87)C:&%R72 H,RD@0T],3$%412!3
M44Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)7T%3($Y53$P@+ T*(%M$5D1=(%MV
M87)C:&%R72 H,RD@0T],3$%412!344Q?3&%T:6XQ7T=E;F5R86Q?0U Q7T-)
M7T%3($Y53$P@+ T*(%M)1%T@6VYU;65R:6-=*#$P+" P*2!)1$5.5$E462 H
M,2P@,2D@3D]4($Y53$P-"BD@3TX@6U!224U!4EE=#0I'3PT*04Q415(@5$%"
M3$4@271E;4AA<F1W87)E(%=)5$@@3D]#2$5#2R!!1$0@4%))34%262!+15D@
M0TQ54U1%4D5$("A/<F1E<DYO*0T*9V\-"B\J("TM($=O="!T:&4@9F]L;&]W
M:6YG('=A<FYI;F<@=VAE;B!C<F5A=&EN9R!T86)L93H@271E;4AA<F1W87)E
M#0I787)N:6YG.B!4:&4@=&%B;&4@)TET96U(87)D=V%R92<@:&%S(&)E96X@
M8W)E871E9"!B=70@:71S(&UA>&EM=6T@<F]W('-I>F4@*#(T-3,R*2!E>&-E
M961S('1H92!M87AI;75M(&YU;6)E<B!O9B!B>71E<R!P97(@<F]W("@X,#8P
M*2X@#0I)3E-%4E0@;W(@55!$051%(&]F(&$@<F]W(&EN('1H:7,@=&%B;&4@
M=VEL;"!F86EL(&EF('1H92!R97-U;'1I;F<@<F]W(&QE;F=T:"!E>&-E961S
M(#@P-C @8GET97,N#0HJ+PT*+2T@26YS97)T(%-A;7!L92!D871A#0II;G-E
M<G0@:6YT;R!)=&5M2&%R9'=A<F4@=F%L=65S("@G,# P,2<L("=4:&ES(&ES
M($QA8F5L(# P,#$@;V8@<F]W(&]N92!3=')A;F=E<B<L3E5,3"Q.54Q,+$Y5
M3$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,*0T*
M:6YS97)T(&EN=&\@271E;4AA<F1W87)E('9A;'5E<R H)S P,#(G+" G5&AI
M<R!I<R!,86)E;" P,# R(&]F(')O=R!T=V\@4W1I;F<G+$Y53$PL3E5,3"Q.
M54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"D-
M"FEN<V5R="!I;G1O($ET96U(87)D=V%R92!V86QU97,@*"<P,# S)RP@)U1H
M:7,@:7,@3&%B96P@,# P,R!O9B!R;W<@=&AR964@4U%,(%-E<G9E<B<L3E5,
M3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,
M3"Q.54Q,*0T*:6YS97)T(&EN=&\@271E;4AA<F1W87)E('9A;'5E<R H)S P
M,#0G+" G5&AI<R!I<R!,86)E;" P,# T(&]F(')O=R!F;W5R($]204-,12<L
M3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL
M3E5,3"Q.54Q,*0T*+2T@<F]W($Y/5"!I;B!)=&5M5&ET;&5S+"!B=70@:7,@
M:6X@271E;5-T;V-K#0II;G-E<G0@:6YT;R!)=&5M2&%R9'=A<F4@=F%L=65S
M("@G,# P-2<L("=4:&ES(&ES($QA8F5L(# P,#4@;V8@<F]W(&9I=F4@26YT
M97)F86-E)RQ.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y53$PL3E5,3"Q.54Q,+$Y5
M3$PL3E5,3"Q.54Q,+$Y53$PI#0IG;PT*#0HM+2!C;VYF:7)M('-A;7!L92!D
M871A(&%N9"!&5"UE;F%B;&4@=&%B;&5S('9I82!%;G1E<G!R:7-E($UA;F%G
M97(N+BX-"G-E;&5C=" J(&9R;VT@271E;5-T;V-K#0HM+2!T<G5N8V%T92!T
M86)L92!)=&5M4W1O8VL-"G-E;&5C=" J(&9R;VT@271E;51I=&QE<PT*+2T@
M=')U;F-A=&4@=&%B;&4@271E;51I=&QE<PT*<V5L96-T("H@9G)O;2!)=&5M
M2&%R9'=A<F4-"BTM('1R=6YC871E('1A8FQE($ET96U(87)D=V%R90T*9V\-
M"@T*+2T@#0HM+2!/<FEG:6YA;"!P<F]B;&5M('%U97)Y+"!W;W)K<R!W:71H
M('1H92!A8F]V92!D871A+"!B=70@;VYL>2!W:71H(&$@8V]M;6]N('=O<F0@
M(G)O=R(@:7,@<75E<FEE9"!F<F]M(&%L;"!T:')E92!T86)L97,N#0I$14-,
M05)%($!396%R8VA#<FET97)I82!V87)C:&%R*#$P,"D-"E-%5"! 4V5A<F-H
M0W)I=&5R:6$@/2 G(")R;W<J(B G("TM('!R:6UA<GD@<V5A<F-H(&-O;'5M
M;B!I<R!)=&5M4W1O8VLN3&%B96P@*&]T:&5R(&-O;'5M;G,L(&QE9G0@3E5,
M3"D-"E-%3$5#5"!)=&5M4W1O8VLN3W)D97).;RQ)=&5M4W1O8VLN3&%B96P@
M#0I&4D]-($ET96U3=&]C:PT*("!)3DY%4B!*3TE.($ET96U4:71L97,@("!/
M3B!)=&5M4W1O8VLN3W)D97).;R ]($ET96U4:71L97,N3W)D97).;PT*("!)
M3DY%4B!*3TE.($ET96U(87)D=V%R92!/3B!)=&5M4W1O8VLN3W)D97).;R ]
M($ET96U(87)D=V%R92Y/<F1E<DYO#0H@($E.3D52($I/24X@1E)%151%6%14
M04),12A)=&5M4W1O8VLL("HL($!396%R8VA#<FET97)I82D@05,@1E-?5$%"
M3$4@3TX@1E-?5$%"3$4N6TM%65T@/2!)=&5M4W1O8VLN3W)D97).;PT*(" @
M("!/4D1%4B!"62!&4U]404),12Y286YK($1%4T,-"BTM(#%S="!T97-T.B T
M(')O=W,@8F5C87-U92!O;FQY($ET96U3=&]C:R!I<R!R969E<F5N8V5D(&EN
M($92145415A45$%"3$4@8VQA<W5E#0H-"@T*+2T@36]D:69E9"!/<FEG:6YA
M;"!Q=65R>0T*1$5#3$%212! 4V5A<F-H0W)I=&5R:6$@=F%R8VAA<B@Q,# I
M#0I3150@0%-E87)C:$-R:71E<FEA(#T@)R B<F]W*B(@)R @+2T@5&5S="!W
M:71H(&)O=&@@8V]N=&%I;G-T86)L92 F(&9R965T97AT($%.1"!/4B!"971E
M=V5N(&9O<B!E>'!E8W1E9"!R97-U;'1S#0I314Q%0U0@9&ES=&EN8W0@92Y/
M<F1E<DYO+"!E+DQA8F5L("TM(&1I<V-T:6YC="!R97%U<FEE9"!T;R!G970@
M-2!R;W=S+"!S=&EL;"!N;W0@97AA8W1L>2!S86UE(&%S(&%B;W9E+BXN#0IF
M<F]M($ET96U3=&]C:R!!4R!E+"!)=&5M5&ET;&5S('0L($ET96U(87)D=V%R
M92!H+ T*(" @("!F<F5E=&5X='1A8FQE*$ET96U3=&]C:RP@3&%B96PL($!3
M96%R8VA#<FET97)I82D@87,@02P-"B @(" @9G)E971E>'1T86)L92A)=&5M
M5&ET;&5S+"!4:71L92P@0%-E87)C:$-R:71E<FEA*2!A<R!"+ T*(" @("!F
M<F5E=&5X='1A8FQE*$ET96U(87)D=V%R92P@<U]P86=E+"! 4V5A<F-H0W)I
M=&5R:6$I(&%S($,-"B @(" @("!W:&5R90T*(" @(" @(" @02Y;2T5972 ]
M(&4N3W)D97).;R!A;F0-"B @(" @(" @($(N6TM%65T@/2!T+D]R9&5R3F\@
M86YD#0H@(" @(" @("!#+EM+15E=(#T@:"Y/<F1E<DYO#0HM+2 Q<W0@=&5S
M=#H@3D]4('1H92!S86UE(&%S(&%B;W9E(&%S('1H:7,@<75E<GD@9V5T<R U
M(')O=W,L(&%D9&ET:6]N86P@<F]W(&ES(")4:&ES(&ES($QA8F5L(# P,#4@
M;V8@<F]W(&9I=F4@26YT97)F86-E(@T*#0H-"BTM(%1E<W0@=VET:"!B;W1H
M(&-O;G1A:6YS=&%B;&4@)B!F<F5E=&5X="!!3D0@3U(@0F5T97=E;B!E86-H
M(0T*4T5,14-4(&1I<W1I;F-T(&4N3W)D97).;RP@92Y,86)E; T*9G)O;2!)
M=&5M4W1O8VL@05,@92P@271E;51I=&QE<R!T+ T*(" @("!C;VYT86EN<W1A
M8FQE*$ET96U3=&]C:RP@3&%B96PL("=":6QL>2<I(&%S($$L#0H@(" @(&-O
M;G1A:6YS=&%B;&4H271E;51I=&QE<RP@5&ET;&4L("=3=')A;F=E<B<I(&%S
M($(@+2T@;F]W(&=E='1I;F<@<F5S=6QT<R A($UU<W0@:&%V92!C;VQU;6XM
M<W!E8VEF:6,@<V5A<F-H('=O<F0A#0H@(" @(" @=VAE<F4-"B @(" @(" @
M($$N6TM%65T@/2!E+D]R9&5R3F\@;W(@+2T@3U(@+2T@9V5N97)A=&5S(&QA
M<F=E<B!R97-U;'0L('-O('5S92!D:7-T:6YC="!E+D]R9&5R3F\L(')E='5R
M;G,@-2!R;W=S('=I=&@@9&ES=&EN8W0-"B @(" @(" @($(N6TM%65T@/2!T
M+D]R9&5R3F\-"@T*<V5L96-T("H@9G)O;2!)=&5M4W1O8VL@=VAE<F4@8V]N
M=&%I;G,H*BPG0FEL;'DG*2 M+2!R971U<FYS(#$@<F]W+@T*#0H-"BTM($UO
M9&EF:65D($]R:6=I;F%L('%U97)Y+"!R96UO=F5D('1H92! 4V5A<F-H0W)I
M=&5R:6$@=F%R:6%B;&4@=&\@=&5S="!W:71H('1A8FQE(&%N9"!C;VQU;6XM
M<W!E8VEF:6,@<V5A<F-H('=O<F1S#0I314Q%0U0@9&ES=&EN8W0@92Y/<F1E
M<DYO+"!E+DQA8F5L#0IF<F]M($ET96U3=&]C:R!!4R!E+"!)=&5M5&ET;&5S
M('0L($ET96U(87)D=V%R92!H+ T*(" @("!C;VYT86EN<W1A8FQE*$ET96U3
M=&]C:RP@3&%B96PL("=":6QL>2<I(&%S($$L#0H@(" @(&-O;G1A:6YS=&%B
M;&4H271E;51I=&QE<RP@5&ET;&4L("=3=')A;F=E<B<I(&%S($(L#0H@(" @
M(&-O;G1A:6YS=&%B;&4H271E;4AA<F1W87)E+"!S7W!A9V4L("=R;W<G*2!A
M<R!##0H@(" @(" @=VAE<F4-"B @(" @(" @($$N6TM%65T@/2!E+D]R9&5R
M3F\@86YD("TM($]2(#T@9V5N97)A=&5S(&UU=&EP;&4@<F]W<RP@86YD('1H
M97)E9F]R92!N965D<R @9&ES=&EN8W0@92Y/<F1E<DYO+@T*(" @(" @(" @
M0BY;2T5972 ]('0N3W)D97).;R!A;F0-"B @(" @(" @($,N6TM%65T@/2!H
M+D]R9&5R3F\-"BTM(#%S="!T97-T.B P(')O=W,L('-A;64@87,@86)O=F4-
9"@T*+2T@/&5O9CX-"@T*#0H-"@T*#0H-"@``
`
end
- Next message: John Kane: "Re: OLE DB provider 'MSIDXS' reported an error. Access denied."
- Previous message: John Kane: "Re: CONTAINS performance"
- In reply to: malcolm.earnest_at_bom.co.uk: "Re: CONTAINS performance"
- Next in thread: malcolm.earnest_at_bom.co.uk: "Re: CONTAINS performance"
- Reply: malcolm.earnest_at_bom.co.uk: "Re: CONTAINS performance"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
