Re: Incremental population stops

• Previous message: John: "Re: Incremental population stops"
• In reply to: John: "Re: Incremental population stops"
• Next in thread: John: "Re: Incremental population stops"
• Reply: John: "Re: Incremental population stops"
• Reply: John: "Re: Incremental population stops"
• Messages sorted by: [ date ] [ thread ]

Date: Mon, 4 Oct 2004 15:09:20 -0700

John,
Yes, I would have to agree with both of your points, especially #2 unless
other punctuation characters (such as ., # or ;, etc.) are in contact with
the search words... I've attached a sql script file
(FTS_with_Change_Tracking_pooling.sql) that demonstrates the time it takes
to insert 1 row (or document) and then to get a successful return from a FTS
query and how long it takes. I'd recommend that you alter this script and
test it with your data and then change the WAITFOR DELAY until you get a
valid response. Note, you should execute the DELETE to WAITFOR as a batch
starting with 1 second and increasing until you get a return of 1 row
affected.

I've forwarded this script to Microsoft, but have yet to hear back as to
whether or not this is a bug or a PRB. Most likely in your case, the
MSSearch service is not able to take the push of data from SQL Server at
your rate and the stop / restart of the MSSearch service clears up whatever
error or issue is at the heart of this problem.

I'd also recommend that you review the problem server's Application event
log for any source events from "Microsoft Search" or MssCi (informational,
warnings & errors) prior to the time of stopping & re-starting the MSSearch
service. If you find any suspect entries, could you post them here?

While the XML Ifilters might not be the solution for this issue, it was
provide as FYI, in case you did hit the bug# I made reference to in my below
reply.

Regards,
John

"John" <John@Comprompter.com> wrote in message
news:uLz$tklqEHA.556@TK2MSFTNGP11.phx.gbl...
> Interesting. I'm not sure the bug you mentioned would apply, for two
> reasons.
>
> 1) The search query succeeds on the new data after the search service has
> been restarted, indicating (to me) that the service never indexed the row
to
> begin with.
> 2) The bug sounds to me as if it could only affect words at the beginning
> and end of one of our paragraphs (which is the only place the words the
> users search for could meet with an XML element tag). But, once the
> behavior is noticed, they realize that no query successfully returns data
> from the newer items, but old data comes through.
>
> I'm also wondering what value the IFilter would really provide, since the
> users aren't actually querying for XML content, but for content within the
> <paragraph></paragraph> tags within the XML. Also, it sounds like a lot
of
> work for us and another expense for the clients. I'd need to understand
the
> point a little better.
>
> John
>
>
> "John Kane" <jt-kane@comcast.net> wrote in message
> news:%23V6kDElqEHA.896@TK2MSFTNGP12.phx.gbl...
> > You're welcome, John
> > At the below frequency (timing) and amount (number of rows
> > updated/inserted)
> > levels, the log based sysfulltextnotify push to the MSSearch services
> > *should* be able to keep up with the updates, both for your larger and
> > smaller tables. However, without knowing what they were searching for
and
> > did not find in the recent updates, this may be a different issue and
> > stopping & re-starting the MSSearch service may be hiding this issue.
> >
> > Since you are storing your XML data in a column defined with a TEXT
> > datatype
> > AND your are using SQL Server 2000 SP3 on Windows 2000 Server, the
*real*
> > issue may be how the XML metatags are or are not in contact with the
> > search
> > word. This can only be determined by looking at the actual XML code and
> > determining if the <tag>search_word</tag> is in contact with the
> > search_word
> > for recently updated rows.
> >
> > There is a well known (within this newsgroup) bug (Shiloh bug# 351310
> > "Full
> > Text Search Win2K word breaker does not ignore punctuation unless
> > separated
> > by white space") that when search text is combined with HTML or XML
> > metatags
> > in non-IMAGE datatypes, that the search_word cannot be found because the
> > XML
> > or HTML metatags are in contact or touching the < or > punctuation
> > characters on Windows 2000 Server, but not on Windows Server 2003 as it
> > has
> > a new wordbreaker. For a workaround to this bug on Win2K, you can use
the
> > Neutral "Language for Word Breaker" for your XML column and then run a
> > Full
> > Population. Note, if you switch to the Neutral wordbreaker, you will
lose
> > some SQL FTS functionality, specifically formsof(inflectional) that is
> > language specific as the Neutral word breaker breaks the works based
upon
> > the "white space" between the words.
> >
> > A more long term solution is to store your xml files in a column using
the
> > IMAGE datatype, and use a "file extension" column of char(3) or char(4)
to
> > contain the file extension, for XML, use xml or .xml (note the period
> > before
> > xml). You then can download and install the Microsoft Sharepoint-based
XML
> > iFilter at
> >
http://www.microsoft.com/sharepoint/server/techinfo/reskit/XML_Filter.asp,
> > keeping in mind that to index attributes/elements which have values
> > greater
> > than 32 characters you need to install OfficeXP locally on your IS
> > machine.
> >
> > The XML iFilter will index (1) values of sub-elements of the root
element
> > when the sub elements have no child elements and (2) attributes of the
> > root
> > element and attributes of sub-elements of the root element. Consider a
> > sample XML document:
> >
> > <?xml version="1.0" ?>
> > <book title="YourBook">
> > This a book chapter
> > <author>
> > First Last
> > <AGE>20</AGE>
> > </author>
> > <ISBN>
> > 222222222
> > </ISBN>
> > </book>
> >
> > The attribute Title of the element Book, and ISBN would be the only
values
> > that would be indexed and query able in this case.You might want to
> > consider
> > alternatives to Microsoft's Sharepoint XML Ifilter, such as: QuiLogic at
> > http://www.quilogic.cc/ifilter.htm or 3 Tier Technology at
> > http://www.3tt.com.au/products/xmlFilter/default.html
> >
> > I'd recommend that you first test the XML results differences on Win2003
> > vs.
> > Win2K and if that is not the true issue, then consider the above XML
> > Ifilters as this will require a table schema change as well as related
> > application change.
> >
> > Regards,
> > John
> >
> >
> >
> > "John" <John@Comprompter.com> wrote in message
> > news:uc2LpxkqEHA.1152@TK2MSFTNGP11.phx.gbl...
> >> Hi,
> >>
> >> You're definitely digging deep, as I was hoping for.
> >>
> >> (In reference to the larger catalog) the best way to look at the user's
> >> updating patterns is to begin with the thought that all of the articles
> > are
> >> immediately sent to the database after they are written (and in fact,
may
> > be
> >> sent multiple times AS they are written and editted). There are only
20
> > or
> >> so users doing this work. So, the effect is that the data is not being
> > sent
> >> to the server in batches at all. The model is much closer to
individual
> >> updates sent at evenly spaced intervals throughout the day. (Of
course,
> >> there is the remote possibility that 20 changes or new articles may be
> > added
> >> at once, via separate query operations.)
> >>
> >> The small catalog receives a stream of data that tends to come in small
> >> bursts of maybe 10 items at once.
> >>
> >> They both use a TEXT column type. The OS for the server in question is
> >> Windows 2000.
> >>
> >> Thanks,
> >> John
> >>
> >>
> >> "John Kane" <jt-kane@comcast.net> wrote in message
> >> news:emZaNakqEHA.1160@tk2msftngp13.phx.gbl...
> >> > You're welcome, John,
> >> > I'll try to clarify my questions... Basically and I'm assuming that
> >> > each
> >> > article is a row in your FT-enable table and do they update all of
the
> >> > 100 -
> >> > 500 articles at one time or is do they spread out the updates, such
> >> > that
> >> > 100
> >> > articles are updated (or inserted) at 10:00am, another 100 at
12:00pm,
> >> > another 100 at 2:00pm, and so on? If they update or insert all
(appox.)
> >> > 500
> >> > articles at one time, then this may be too many articles for the SQL
> >> > Server-to-MSSearch push of data (via an un-document system table
> >> > sysfulltextnotify) to handle at one time.
> >> >
> >> > If they are doing the latter and batching the updates or inserts in
> >> > batches
> >> > of (approx.) 100 articles throughout the day, this *may* be a better
> >> > strategy and allow the SQL Server-to-MSSearch push of data to the FT
> >> > Catalog, time to be completed in a reasonable time. Although, 100
> > articles
> >> > at one time, may also be too many, so you may have to have them
update
> > in
> >> > batches of 10 or possibly do the updates one at a time as the
articles
> > are
> >> > posted to SQL Server.
> >> >
> >> > Now, that I have more information, another factor here may also be
the
> >> > fact
> >> > that you are using XML data for the article description and depending
> > upon
> >> > the datatype (varchar, TEXT, nchar or IMAGE, etc.) as well as the OS
> >> > Platform (Win2K or Win2003 ?), you may not be getting the best
results,
> >> > i.e.. finding the expectant results as both the datatype and OS
> >> > Platform
> >> > have issues that can be resolved via using an XML IFilter along with
> >> > storing
> >> > the XML data in an IMAGE datatype. Could you provide more information
> >> > on
> >> > this? Specifically the OS Platform and the datatype that the XML
> >> > description
> >> > is stored in?
> >> >
> >> > Thanks,
> >> > John
> >> >
> >> >
> >> >
> >> > "John" <John@Comprompter.com> wrote in message
> >> > news:uLvn5CkqEHA.2588@TK2MSFTNGP12.phx.gbl...
> >> >> Thanks for the questions,
> >> >>
> >> >> The client has told me that they have SQL Server SP3 installed
> >> >> (8.00.760).
> >> >>
> >> >> I'm not sure I completely understand your question about the
frequency
> > of
> >> >> updates. The client does almost exactly the same thing everyday
(it's
> > a
> >> >> television news station). Each story is an article. The data
stored
> > in
> >> > the
> >> >> full-text column is an xml description of the story, and is
generally
> >> >> between 1K and 6K in size (due to markup and extra non-text data).
> >> >>
> >> >> They will go for several days without this problem occurring, but
then
> >> > they
> >> >> suddenly realize that they need to restart the search service
> >> >> (apparently,
> >> >> on rarer occasions, the propogation won't work correctly until the
> > server
> >> > is
> >> >> rebooted). I can't verify the actual number of rows being used per
> > day,
> >> > but
> >> >> I can say without hesitation, that each day is almost exactly the
same
> > as
> >> >> every other day in terms of content size and number of updates.
> >> >>
> >> >> Thanks,
> >> >> John
> >> >>
> >> >> "John Kane" <jt-kane@comcast.net> wrote in message
> >> >> news:%23mAO73jqEHA.868@TK2MSFTNGP10.phx.gbl...
> >> >> > John,
> >> >> > Thanks for the additional information, that your client has
"Change
> >> >> > Tracking" and "Update Index in Background" as this indicates that
> > they
> >> >> > have
> >> >> > SQL Server 2000. Could you provide some additional info?
> > Specifically,
> >> > the
> >> >> > full output of -- SELECT @@version -- as this is helpful in
> >> >> > troubleshooting
> >> >> > SQL FTS issues such as this.
> >> >> >
> >> >> > The primary issue relates around two facts: (1) recent data
> >> >> > (anywhere
> >> > from
> >> >> > 5
> >> >> > minutes to 5 hours) is not being found when they perform a search
> >> >> > and
> >> > (2)
> >> >> > which is generated at the rate of 100 - 500 articles per day.
Could
> >> >> > you
> >> >> > verify that your client is updating, inserting or deleting 100 -
500
> >> >> > articles (or rows in the FT-enable table) per day? If so, then
this
> >> >> > rate
> >> >> > of
> >> >> > updates, my be too frequently or too many updates for the MSSearch
> >> > service
> >> >> > to push to the FT Catalog in a reasonable timeframe.
> >> >> >
> >> >> > There have been several email threads on this newsgroup that
related
> > to
> >> >> > the
> >> >> > number (total number of rows being updated) and frequency (the
> >> >> > volume
> >> >> > of
> >> >> > rows being updated over time) and that the SQL Server-to-MSSearch
> >> >> > update
> >> >> > process cannot keep up with the *expected* volumes and post the
> > updates
> >> >> > into
> >> >> > the FT Catalog in a reasonable amount of time. I have a simple
repro
> > of
> >> >> > this
> >> >> > for a one row update that should post to the FT Catalog in 1
second,
> >> >> > but
> >> >> > does not post until at least 5 to 7 seconds for only one row and I
> > have
> >> >> > forwarded this to Microsoft as well as others have opened support
> > cases
> >> >> > with
> >> >> > Microsoft on this issue. At this time, I do not know the status of
> > this
> >> >> > issue, or if this has been confirmed as a bug or as a PRB (a known
> >> > issue,
> >> >> > but not a bug).
> >> >> >
> >> >> > Thanks and any additional information you can provide would be
> > helpful!
> >> >> > John
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > "John" <John@Comprompter.com> wrote in message
> >> >> > news:OJFaiJjqEHA.592@TK2MSFTNGP11.phx.gbl...
> >> >> >> I can't answer that definitively, but the client has told me that
> > they
> >> >> > found
> >> >> >> no relevant error messages...
> >> >> >>
> >> >> >> Reading my previous post, I noticed two things that I should
clear
> > up.
> >> >> >>
> >> >> >> 1) The larger catalog uses a table with a timestamp column
(titled
> >> >> >> "LastChanged"). The smaller catalog refers to a table without a
> >> >> >> timestamp
> >> >> >> column.
> >> >> >>
> >> >> >> 2) The proper terms for the index settings that are being used --
> >> > change
> >> >> >> tracking, and background update (with no scheduled populations).
> >> >> >>
> >> >> >> Thanks,
> >> >> >> John
> >> >> >>
> >> >> >>
> >> >> >> "Hilary Cotter" <hilary.cotter@gmail.com> wrote in message
> >> >> >> news:uDAceBjqEHA.1164@TK2MSFTNGP10.phx.gbl...
> >> >> >> > are there any errors or warnings in the event log from MSSCi,
or
> >> >> > MSSearch?
> >> >> >> >
> >> >> >> > --
> >> >> >> > Hilary Cotter
> >> >> >> > Looking for a SQL Server replication book?
> >> >> >> > http://www.nwsu.com/0974973602.html
> >> >> >> >
> >> >> >> >
> >> >> >> > "John" <John@Comprompter.com> wrote in message
> >> >> >> > news:eyTMg7iqEHA.3848@TK2MSFTNGP14.phx.gbl...
> >> >> >> >> Hi,
> >> >> >> >>
> >> >> >> >> I've got what I believe to be an unusual situation. One of
our
> >> >> >> >> clients
> >> >> >> >> is
> >> >> >> >> reporting that they need to randomly restart the MSSearch
> > service.
> >> >> > They
> >> >> >> >> detect this need by noticing that recent data (anywhere from 5
> >> > minutes
> >> >> > to
> >> >> >> > 5
> >> >> >> >> hours) is not being found when they performa a search.
However,
> >> >> >> >> the
> >> >> >> > search
> >> >> >> >> itself succeeds, returning the old data that matches their
> >> >> >> >> query.
> >> >> >> >>
> >> >> >> >> Apparently, the index has decided to stop updating for
whatever
> >> >> >> >> reason,
> >> >> >> > and
> >> >> >> >> giving the MSSearch service a kick will correct the issue for
a
> >> > while.
> >> >> >> >>
> >> >> >> >> What (if anything) can be done about this? The client reports
> > that
> >> >> > there
> >> >> >> > is
> >> >> >> >> no relevant information in the event logs.
> >> >> >> >>
> >> >> >> >> Here is a description of the setup:
> >> >> >> >>
> >> >> >> >> A single-CPU machine, average speed, no special hardware
> >> >> >> >> considerations
> >> >> >> > for
> >> >> >> >> the database. The database and the full-text index reside
> > together
> >> > on
> >> >> > a
> >> >> >> >> single dedicated drive. The full-text index is set to do
> >> >> >> >> background
> >> >> >> >> updating, incremental poplution. I am not sure whether both
> >> > manifest
> >> >> > the
> >> >> >> >> same behavior simultaneously. One catalog deals with years of
> >> >> >> >> client-created data, which is generated at the rate of 100 -
500
> >> >> > articles
> >> >> >> >> per day. The other catalog deals with externally generated
> >> >> > information,
> >> >> >> > and
> >> >> >> >> only retains one week of that data. (Every evening it purges
the
> >> >> > content
> >> >> >> >> older than a week.)
> >> >> >> >>
> >> >> >> >> Please offer whatever clues you can, even if you think it may
be
> > an
> >> >> >> >> incomplete answer.
> >> >> >> >>
> >> >> >> >> John
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>

begin 666 FTS_with_Change_Tracking_pooling.sql
M#0HM+0E&:6QE;F%M93H)1E137W=I=&A?0VAA;F=E7U1R86-K:6YG7W!O;VQI
M;F<N<W%L#0HM+0E0=7)P;W-E.@E4;R!T97-T($9422!A;F0@1E13('=I=&@@
M0VAA;F=E('1R86-K:6YG(&%N9"!U<&1A=&4@:6YD97@@:6X@8F%C:V=R;W5N
M9"!A;F0@<WES9G5L;'1E>'1N;W1I9GD@<&]O;&EN9PT*+2T)16YV:7)O;65N
M=#H)57-I;F<@4U%,(#(P,# @4U S(&]N(%=I;F1O=W,@4V5R=F5R(#(P,#,@
M4E1-#0HM+0E-;V1I9FEE9#H),3$Z,S @04T@,R\Q,2\R,# T#0H-"@T*#0IU
M<V4@<'5B<PT*9V\-"G-E;&5C="! 0'9E<G-I;VX@+2T@36EC<F]S;V9T(%-1
M3"!397)V97(@(#(P,# @+2 X+C P+C<V," H4U S*2!A;F0@."XP,"XU,S0@
M*%-0,BD-"F=O#0II9B!E>&ES=',@*'-E;&5C=" J(&9R;VT@<WES;V)J96-T
M<R!W:&5R92!I9" ](&]B:F5C=%]I9"@G1E135&%B;&4G*2D-"B @9')O<"!T
M86)L92!&5%-486)L90T*9V\-"D-214%412!404),12!&5%-486)L92 H#0H@
M($ME>4-O; EI;G0@241%3E1)5%D@*#$L,2D@3D]4($Y53$P@#0H@(" @0T].
M4U1204E.5"!&5%-486)L95])1%@@4%))34%262!+15D@0TQ54U1%4D5$+ T*
M("!497AT0V]L"71E>'0@3E5,3"P-"B @26UA9V5#;VP):6UA9V4@3E5,3"P-
M"B @17AT0V]L"6-H87(H,RD@3E5,3"P@+2T@8V%N(&)E('-Y<VYA;64-"B @
M5&EM95-T86UP0V]L"71I;65S=&%M<"!.54Q,( T**0T*9V\-"@T*+2T@5')U
M;F-A=&4@1&%T82P@:68@;F5C97-S87)Y+BX-"BTM(%1254Y#051%(%1!0DQ%
M($944U1A8FQE#0I);G-E<G0@1E135&%B;&4@=F%L=65S("@G36%R>2!H860@
M82!L:71T;&4@;&%M8B<L(')E<&QI8V%T92@G,'@Q)RPQ,# I+" G='AT)RP@
M3E5,3"D-"DEN<V5R="!&5%-486)L92!V86QU97,@*"=->2!D;V<@8F%R:V5D
M(&QO=61L>2<L(')E<&QI8V%T92@G,'@W)RPS,# I+" G='AT)RP@3E5,3"D@
M#0I);G-E<G0@1E135&%B;&4@=F%L=65S("@G5&AE(&9O>"!J=6UP960@;W9E
M<B!T:&4@9F5N8V4G+"!R97!L:6-A=&4H)S!X."<L.# P*2P@)W1X="<L($Y5
M3$PI#0I);G-E<G0@1E135&%B;&4@=F%L=65S("@G22!D;W9E(&EN=&\@=&AE
M('!O;F0G+"!R97!L:6-A=&4H)S!X,B<L,3 P*2P@)W1X="<L($Y53$PI#0H-
M"@T*+2T@1G5L;"U497AT($EN9&5X:6YG("A&5$DI('-E='5P('5S:6YG(")#
M:&%N9V4@5')A8VMI;F<B(&%N9" B57!D871E($EN9&5X(&EN($)A8VMG<F]U
M;F0B+BXN#0IE>&5C('-P7V9U;&QT97AT7V-A=&%L;V<@)T944T-A=&%L;V<G
M+"=C<F5A=&4G#0IE>&5C('-P7V9U;&QT97AT7W1A8FQE("=&5%-486)L92<L
M)V-R96%T92<L)T944T-A=&%L;V<G+"=&5%-486)L95])1%@G#0IE>&5C('-P
M7V9U;&QT97AT7V-O;'5M;B G1E135&%B;&4G+"=497AT0V]L)RPG861D)R M
M+2!A<W-U;65S($5N9VQI<V@@;&%N9W5A9V4@=&5X= T*97AE8R!S<%]F=6QL
M=&5X=%]C;VQU;6X@)T944U1A8FQE)RPG26UA9V5#;VPG+"=A9&0G+" P># T
M,#DL("=%>'1#;VPG(" -"F=O#0H-"BTM(%-T87)T($94($EN9&5X:6YG+BXN
M(&%N9"!C;VYF:7)M('9I82 B36EC<F]S;V9T(%-E87)C:"(@<V]U<F-E(&5N
M=')I97,@:6X@=&AE('-E<G9E<B=S($%P<&QI8V%T:6]N($5V96YT(&QO9RXN
M+@T*15A%0R!S<%]F=6QL=&5X=%]T86)L92 G1E135&%B;&4G+" G4W1A<G1?
M8VAA;F=E7W1R86-K:6YG)PT*+RH@+2T@<F5T=7)N<R H;VX@4U%,(#(P,# @
M4U S*0T*5V%R;FEN9SH@5&%B;&4@)T944U1A8FQE)R!D;V5S(&YO="!H879E
M('1H92!O<'1I;VX@)W1E>'0@:6X@<F]W)R!E;F%B;&5D(&%N9"!H87,@9G5L
M;"UT97AT(&EN9&5X960@8V]L=6UN<R -"G1H870@87)E(&]F('1Y<&4@:6UA
M9V4L('1E>'0L(&]R(&YT97AT+B!&=6QL+71E>'0@8VAA;F=E('1R86-K:6YG
M(&-A;FYO="!T<F%C:R!74DE4151%6%0@;W(@55!$051%5$585"!O<&5R871I
M;VYS( T*<&5R9F]R;65D(&]N('1H97-E(&-O;'5M;G,N#0HJ+PT*15A%0R!S
M<%]F=6QL=&5X=%]T86)L92 G1E135&%B;&4G+" G4W1A<G1?8F%C:V=R;W5N
M9%]U<&1A=&5I;F1E>"<-"F=O#0H-"@T*+2T@16YV:7)O;65N=#H@4U%,(#(P
M,# @4U R(&]N(%=I;C)+("8@4U%,(#(P,# @4U S(&]N(%=I;C(P,#,-"@T*
M+2T@4F5P;R!I;G-T<G5C=&EO;G,Z#0HM+2 Q+B!#:&%N9V4@=&AE(%=!251&
M3U(@1$5,05D@)S P.C P.C!8)R!8('9A;'5E+"!S=&%R=&EN9R!A=" Q('-E
M8V]N9"!A;F0@:6YC<F5M96YT:6YG('5N=&EL('1H92!S96QE8W0@<F5T=7)N
M<R Q(')O=RX-"BTM(#(N($AI9VAL:6=H="!T:&4@8F5L;W<@8V]D92!A;F0@
M97AE8W5T92X-"@T*+2T@26YS97)T(&%D9&ET:6]N86P@86YD('5N:7%U92!W
M;W)D('=I=&@@0U0@86YD(%5):4(@96YA8FQE9" M($1E;&5T92P@26YS97)T
M(&%N9"!I;F-R96%S92!W86ET9F]R(&1E;&%Y('5N=&EL('-E;&5C=" Q(')O
M=PT*1$5,151%($944U1A8FQE('=H97)E(%1E>'1#;VP@;&EK92 G)71E>'0E
M)R M+2!D96QE=&4@:6YS97)T960@<F]W+"!I9B!N96-E<W-A<GD-"F=O#0I)
M3E-%4E0@1E135&%B;&4@=F%L=65S*"=497-T(%1%6%0@1&%T82!F;W(@<F]W
M(#4G+"!.54Q,+" G9&]C)RP@3E5,3"D@#0IG;PT*5T%)5$9/4B!$14Q!62 G
M,# Z,# Z,#4G("TM('=A:70@9F]R('@@<V5C;VYD<R!A;F0@=&AE;B!R=6X@
M4U%,($944R!Q=65R>2!T;R!G970@97-T:6UA=&4@;V8@<F5T=7)N('1I;64-
M"G-E;&5C="!497AT0V]L(&9R;VT@1E135&%B;&4@=VAE<F4@8V]N=&%I;G,H
M5&5X=$-O;"PG=&5S="<I#0HO*B M+2!W:71H(%=!251&3U(@1$5,05D@<V5T
M('1O(#4@<V5C;VYD<SH-"B@Q(')O=RAS*2!A9F9E8W1E9"D-"B@Q(')O=RAS
M*2!A9F9E8W1E9"D-"@T*5&5X=$-O;" @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @(" @(" @(" @(" @#0HM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2 -"E1E<W0@5$585"!$871A
M(&9O<B!R;W<@-0T**#$@<F]W*',I(&%F9F5C=&5D*0T**B\-"@T*+2T@4W5M
M;6%R>3H@37D@=&5S=&EN9R!I;F1I8V%T97,@=&AA="!O;FQY(&%F=&5R(&$@
M-2!T;R V('-E8V]N9',@=V%I=&9O<B!D96QA>2!W:6QL('1H92!S96QE8W0@
M<F5T=7)N(&$@:&ET(&%N9"!I9B!Y;W4@:6YC<F5A<V4-"BTM(" @(" @(" @
M('1H92!W86ET9F]R(&1E;&%Y('1O(#<@<V5C;VYD<RP@:70@<W1I;&P@;6%Y
M(&YO="!C;VYS:7-T96YT;'D@<F5T=7)N(#$@<F]W+B!!9&1I=&EO;F%L;'DL
M('-O;65T:6UE(&5V96X@:68@>6]U(&1O('5S90T*+2T)(" @(#4@<V5C;VYD
M<RP@86YD(&EF('EO=2!R92UR=6X@=&AE(&AI9VAL:6=H=&5D('%U97)Y+"!Y
M;W4@;6%Y('-T:6QL(&YO="!G970@82!R971U<FX@;V8@,2!R;W<N#0H-"@T*
M#0H-"B\J("TM($-L96%N('5P.B!5;BUC;VUM96YT('1H92!F;VQL;W=I;F<@
M8V]D92!T;R!R96UO=F4@=&AE($94($-A=&%L;V<L('1A8FQE<PT*=7-E(%!U
M8G,-"F=O#0IE>&5C('-P7V9U;&QT97AT7W1A8FQE("=&5%-486)L92<L)V1R
M;W G#0IE>&5C('-P7V9U;&QT97AT7T-A=&%L;V<@)T944T-A=&%L;V<G+"=D
C<F]P)PT*9')O<"!T86)L92!&5%-486)L90T*9V\-"BHO#0H`
`
end

• Previous message: John: "Re: Incremental population stops"
• In reply to: John: "Re: Incremental population stops"
• Next in thread: John: "Re: Incremental population stops"
• Reply: John: "Re: Incremental population stops"
• Reply: John: "Re: Incremental population stops"
• Messages sorted by: [ date ] [ thread ]