Subject | Re: is there bug on terminator? |
---|---|
Author | Antonio Carlos Ribeiro |
Post date | 2007-08-23T00:55:43Z |
--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
We are just trying to upgrade our application from Firebird 1.5.x to
2.0.x, so, this is a pretty old code of ours. I'm executing it in
ib_script and you can reproduce this error in the "execute script"
tool of "IB_SQL 4.7.Beta 15".
But you won't be able to reproduce it in IB_SQL 4.3A (wich I was still
using until yesterday). On this version of IB_SQL it works fine both
way, with or without blanks.
Antonio
>connected yet.
> At 08:31 AM 23/08/2007, you wrote:
> >Antonio,
> >
> > > Hi there!
> > >
> > > // ------------ Scenario:
> > >
> > > Delphi 7
> > > FirebirdSQL 1.5.4
> > > IBObjects 4.8.6
> > > IB_SQL 4.7.Beta 15 (for testing purposes)
> > >
> > > // ------------ In a trigger like this:
> > >
> > > SET TERM !! ;
> > > CREATE OR ALTER TRIGGER SET_GEN_L_CRITICA FOR MYTABLE
> > > BEFORE INSERT AS BEGIN
> > > DELETE FROM MYTABLE2;
> > > END!!
> > > SET TERM ; !!
> > >
> > > // ------------ I got the following message:
> > >
> > > Token Unknown - line 4, char 4
> > >
> > > // ------------ Adding a space between END and !! it works:
> > >
> > > ...
> > >
> > > END !!
> > > SET TERM ; !!
> > >
> > > // ---------------------------------------------------------
> > >
> > > Am I missing something?
> >
> >The way you declared your terminator put a space after it:
> >
> >SET TERM !! ;
>
> I disagree with this as a principle. If terminators are going to be
> allowed, they should behave as they do in ISQL.
> In ISQL a terminator can be any sequence of characters (including
> embedded blanks) and leading and trailing blanks are ignored:
>
> c:\Program Files\Firebird\Firebird_1_5\bin>isql
> Use CONNECT or CREATE DATABASE to specify a database
> SQL> set term ^^;
> SQL> show sql dialect^^
> Client SQL dialect has not been set and no database has been
> SQL> set term ;;;^^connected yet.
> SQL> show sql dialect;;;
> Client SQL dialect has not been set and no database has been
> SQL> set term ;;;;connected yet.
> SQL> show sql dialect;
> Client SQL dialect has not been set and no database has been
> SQL> set term^;connected yet.
> Command error: set term^
> SQL> set term ^ ;
> SQL> show sql dialect^
> Client SQL dialect has not been set and no database has been
> SQL> set term @ @^connected yet.
> SQL> show sql dialect@ @
> Command error: show sql dialect@
> SQL> show sql dialect @ @
> Client SQL dialect has not been set and no database has been
> SQL>terminator.
>
> According to ISQL rules, the reason why the bad token error occurred
> was because there was NO space between the keyword END and the
>Hi again!
>
>
> >For it to do what you want or expect you should do this:
> >
> > > SET TERM !!;
>
> >The question here is do you think I should trim the whitespace.
> >I don't think this was intentional and trimming the whitespace would
> >probably be a good idea.
> >
> >What do others think?
>
> It is an inconsistency in ISQL (the only environment where terminator
> switching is actually *valid*) that you are allowed to have zero
> white space between a syntax element when the terminator is a
> semi-colon but not when it is anything else. I think (STRONGLY!!)
> that, if you are going to change the terminator-handling behaviour,
> you should aim to make it consistent with ISQL, including ISQL's own
> inconsistency, so that it will be possible to use an isql-created
> script as the input to an ib_script and vice versa.
>
> It would be interesting for Antonio to tell us exactly where he
> bumped into this problem:
> -- If it was in executing an ib_script then there is a case for
> fixing the script parser to get it into line with isql.
> -- If it was in the DSQL tab of IB_SQL (as it appears from his
> original posting) then the mistake was in attempting to use
> terminator switching commands at all in that environment....
>
> Helen
>
We are just trying to upgrade our application from Firebird 1.5.x to
2.0.x, so, this is a pretty old code of ours. I'm executing it in
ib_script and you can reproduce this error in the "execute script"
tool of "IB_SQL 4.7.Beta 15".
But you won't be able to reproduce it in IB_SQL 4.3A (wich I was still
using until yesterday). On this version of IB_SQL it works fine both
way, with or without blanks.
Antonio