Tim

What are the rules that govern when this event fires? I ask because on a table with the structure below (which has full text indexing set on _Message, _Flags,_Subject and _Comments) it seems to fire twice if I simply alter _BoxNo. Both times on _Subject.


Roy Lambert

sl.Add('CREATE TABLE IF NOT EXISTS "MandN"');
sl.Add('(');
sl.Add('   "_BoxNo" INTEGER,');
sl.Add('   "_MsgNo" AUTOINC,');
sl.Add('   "_MsgID" VARCHAR(80),');
sl.Add('   "_InOutInd" VARCHAR(2),');
sl.Add('   "_Parent" INTEGER,');
sl.Add('   "_Thread" INTEGER,');
sl.Add('   "_Status" INTEGER,');
sl.Add('   "_Size" INTEGER,');
sl.Add('   "_MsgUnread" BOOLEAN,');
sl.Add('   "_ThreadUnread" INTEGER,');
sl.Add('   "_PlainText" BOOLEAN,');
sl.Add('   "_WhoFrom" VARCHAR(45),');
sl.Add('   "_WhoTo" VARCHAR(45),');
sl.Add('   "_Received" TIMESTAMP,');
sl.Add('   "_Sent" TIMESTAMP,');
sl.Add('   "_Subject" VARCHAR(100),');
sl.Add('   "_Colour" INTEGER,');
sl.Add('   "_Headers" MEMO,');
sl.Add('   "_Message" MEMO,');
sl.Add('   "_Attachments" MEMO,');
sl.Add('   "_InLine" MEMO,');
sl.Add('   "_Comments" MEMO,');
sl.Add('   "_Flags" MEMO,');
sl.Add('   "_Encoded" MEMO,');
sl.Add('   "_TMaN" MEMO,');
sl.Add('PRIMARY KEY ("_BoxNo","_MsgNo") COMPRESS NONE');
sl.Add('TEXT INDEX ("_Flags")');
sl.Add('LOCALE CODE 2057');
sl.Add('USER MAJOR VERSION 1');
sl.Add(');');

Roy,

<< What are the rules that govern when this event fires? I ask because on a
table with the structure below (which has full text indexing set on
_Message, _Flags,_Subject and _Comments) it seems to fire twice if I simply
alter _BoxNo. Both times on _Subject. >>

That's correct.  When updating a BLOB column, it has to fire twice - once
for the old value so that it can remove the old indexed words from the
index, and once again for the new value so that it can add the new indexed
words.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>That's correct. When updating a BLOB column, it has to fire twice - once
>for the old value so that it can remove the old indexed words from the
>index, and once again for the new value so that it can add the new indexed
>words.

But the key fact here is that I'm not updating any column which is fti'd, only _BoxNo which is an integer.

Also I don't understand the logic of firing it to REMOVE old values surely DBISAM can get those straight from the index and doesn't need this event to preprocess the data?

Roy Lambert

Roy,

<< But the key fact here is that I'm not updating any column which is fti'd,
only _BoxNo which is an integer. >>

It isn't particularly smart about that currently.  It always checks for
updates regardless of whether the columns are actually modified.

<< Also I don't understand the logic of firing it to REMOVE old values
surely DBISAM can get those straight from the index and doesn't need this
event to preprocess the data? >>

It can't obtain that information from the index - it has to get it from the
source used for the index.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>It isn't particularly smart about that currently. It always checks for
>updates regardless of whether the columns are actually modified.

I'm even more confused now. Why does it only seem to check the _Subject column when the _Message, _Flags & _Comments columns are also in the index?

>It can't obtain that information from the index - it has to get it from the
>source used for the index.

Ok I think I can understand the design approach here. Shame though.

Roy Lambert

Roy,

<< I'm even more confused now. Why does it only seem to check the _Subject
column when the _Message, _Flags & _Comments columns are also in the index?
>>

Actually, I was incorrect - only string fields are always checked.  The BLOB
fields are only checked if they were modified, as expected.  Basically,
there is no way currently to tell if a string field was modified or not,
whereas it is possible with the BLOB fields.  The engine can tell if a
string field is different than before, but that doesn't cover situations
where the value is the same, but the string field was actually modified.
That may or may not make a difference, depending upon what one expects to
happen.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Actually, I was incorrect

I love it when you say things like that

>The engine can tell if a
>string field is different than before, but that doesn't cover situations
>where the value is the same, but the string field was actually modified.
>That may or may not make a difference, depending upon what one expects to
>happen.

I had enough entertainment with nulls so I'm not even going to get involved with this one <vbg>

At least it means that the FTI isn't slowing things down much because checking one string field shouldn't take to long.

Roy Lambert

Roy,

<<  I had enough entertainment with nulls so I'm not even going to get
involved with this one <vbg> >>

The short way of saying what I said was:

Sometimes the developer may want any modified string field to be resent
throught the text index filters, etc., even though it may not be different
than the original value.  It's kind of like the Post operation - it is
called when any field is modified, even if the value for the modified field
is the same as it was prior to the modification.

<< At least it means that the FTI isn't slowing things down much because
checking one string field shouldn't take to long. >>

No, not at all.

--
Tim Young
Elevate Software
www.elevatesoft.com