At 04:45 AM 19/01/2007, Luc wrote:

>Maybe it worked ands is a problem now, but still is your statement looks
>worng to me:
>
>You have set it to "!! " +PLUS+ a blank!
>and you reset it by using
>set term ; "!!" (without a blank)
>
>The correct form is:
>set terminator <newterminator><oldterminator>
>without a blank in between.

Luc, this rule may apply in IBO - I don't know, because I don't write
scripts that need to use SET TERM. It could be so, however, since
TIB_Script is not an interface to ISQL, and SET TERM doesn't exist
outside of ISQL. There is some munging going on to get rid of SET
TERM before it hits the interface. TIB_Script has two string
properties SetItem and SetValue where you can (somehow) specify
custom behaviours for SET statements, although I've no idea how it's
meant to work.

A far better way to escape from SET TERM altogether is to not use the
semicolon for your default terminator. If you've ever used the
Extract Metadata tool in IB_SQL you'll see that it applies this style
of usage to the scripts it outputs. IB_Script drops the terminators
anyway, before it sends simple DDL to the interface, since they are
not legal syntax anywhere except in ISQL scripts.

If you write your IB_Script scripts using an alternative terminator
throughout and the semicolon in your PSQL embedded statements (as
required) you can just forget about SET TERM.

create table blah (
id BigInt,
data varchar(50)) ^

commit ^

create trigger bi_blah for blah
active before insert
as
begin
if (new.id is null) then
new.id = gen_id(mygenerator, 1);
end ^

commit ^
..
and so on.

BTW, though it's irrelevant to the current problem, it's not true
that ISQL's SET TERM statement is particular about whether blanks are
included between the symbols and arguments. However, if a blank
occurs between two non-blank characters in the designated replacement
terminator string, the blank will become part of the terminator symbol.

So (in ISQL) you can do

SET TERM H$ ! ;

And the outer-level terminator becomes 'H$ !' until I change it to
something else using another SET TERM statement. *** In ISQL, that is. ***

The experiences reported seem to suggest that the internal handling
of SET TERM might expect a more restricted syntax....all the more
reason not to use it, especially if you are using an ISQL output
file as the source of your IB_Script.

Helen