I'm looking at how I evaluate email rules. I was thinking do as I do now or install one of the scripting languages. Then I had a brainstorm! I already have a nice scripting language built into ElevateDB and I can easily auto generate scripts like:

SCRIPT(IN Headers VARCHAR, IN Msg VARCHAR, OUT Result Boolean)
BEGIN
IF Headers LIKE '%Roy%'
THEN SET Result = TRUE ;
ELSE  SET Result = FALSE;
END IF;
END;

My thinking goes:

1. on starting the email download program create a TList, stuff a TEDBScript into it for each rule to be implemented
2. load those scripts with the autogenerated code
3. for each email loop down the list calling something like

function IsRuleFulfilled(Rule:TEDBScript; const Head, Body:string):boolean;
begin
with Rule do begin
if not Prepared then Prepare;
 if Head <> '' then ParamByName('Headers').AsString := Head;
 if Body <> '' then ParamByName('Msg').AsString := Body;
 ExecScript;
 Result := ParamByName('Result').AsBoolean;
end;
end;

Any comments / thoughts anyone (especially Tim)?

Roy Lambert

Roy,

<< My thinking goes:

1. on starting the email download program create a TList, stuff a
TEDBScript into it for each rule to be implemented
2. load those scripts with the autogenerated code
3. for each email loop down the list calling something like >>

Sounds good to me.  It's essentially what we do with triggers, just with
your own "special" parameters instead of NEWROW/OLDROW.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


Super. In that case a couple of more questions:

First - is it possible to "compile" (ie prepare) and store the compiled version in a table - no big deal if not.

Second - I looked in edbcomps to see if it would be possible to subclass and strip the requirement for a session & database but it looks as though it isn't. The logic is that since for this type of usage I don't need any tables it would be nice to not have to link them in.

How easy would it be for you to produce a script component without that need, or is there a way round it?

In this particular case I can easily point at session and database (even if I don't need them) but I can see a use for scripts where to find a convenient pair to point at will not be easy and I don't fancy (although I will if I have to) creating session and database specifically for this purpose.

Roy Lambert

Tim


Another quick question - do you use a TList or something else?

Roy Lambert

Roy,

<< First - is it possible to "compile" (ie prepare) and store the compiled
version in a table - no big deal if not. >>

No.

<< Second - I looked in edbcomps to see if it would be possible to subclass
and strip the requirement for a session & database but it looks as though it
isn't. The logic is that since for this type of usage I don't need any
tables it would be nice to not have to link them in. >>

You have to link in the whole engine anyways, so I wouldn't worry about it.

<< How easy would it be for you to produce a script component without that
need, or is there a way round it? >>

Is there a particular reason that you want to strip out the database stuff ?
Aren't you already using EDB in the same application ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< How easy would it be for you to produce a script component without that
>need, or is there a way round it? >>
>
>Is there a particular reason that you want to strip out the database stuff ?
>Aren't you already using EDB in the same application ?

I thought

<<In this particular case I can easily point at session and database (even if I don't need them) but I can see a use for scripts where to find a convenient pair to point at will not be easy and I don't fancy (although I will if I have to) creating session and database specifically for this purpose.>>

gave the reason fairly well.

Roy Lambert

Roy,

<< gave the reason fairly well. >>

Not for stripping the database *code* from the .EXE, which is what I thought
you were asking.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


><< gave the reason fairly well. >>
>
>Not for stripping the database *code* from the .EXE, which is what I thought
>you were asking.

Hmm, I can see that would be a tad difficult so I'll give you an extra two days to produce that version OK <vbg>

Roy Lambert

Roy,

<< Hmm, I can see that would be a tad difficult so I'll give you an extra
two days to produce that version OK <vbg> >>

Yeah, sort of an ElevateDB-sans-ElevateDB.

--
Tim Young
Elevate Software
www.elevatesoft.com