Subject | Re: [IB-Architect] gpre bug |
---|---|
Author | Schlottmann-Goedde@t-online.de |
Post date | 2000-11-16T17:16:27Z |
"Ann W. Harrison" schrieb:
words in his c code eg.
/*
* Cancelando a transacao: ROLLBACK
*/
void ib_rollback( STR_ROLLBACK *rollback ) {
sprintf( connid, "%d", rollback->connid );
EXEC SQL ROLLBACK WORK;
rollback->status = SQLCODE;
if ( SQLCODE != 0 ) {
ib_printmsg( "ib_rollback" );
}
}
gpre -e will complain about
(E) e.e:422: expected identifier, encountered ")"
(E) e.e:424: expected identifier, encountered "->"
(E) e.e:428: expected identifier, encountered "->"
so I think the existing user hopefully won't see a difference.
Thanks
Frank
--
"Fascinating creatures, phoenixes. They can carry immensely heavy loads,
their tears have healing powers and they make highly faithful pets."
- J.K. Rowling
http://sourceforge.net/projects/firebird
>Argh, I just have commited this thing.
> Frank,
>
> Sorry to be late with the answer, but I'm slightly swamped.
>The guy who has sent me a test case used some ESQL reserved
> >The same is true if gpre is called with the -e (ignore case) switch,
> >but this will cause other problems.
>
> Dare I ask what?
words in his c code eg.
/*
* Cancelando a transacao: ROLLBACK
*/
void ib_rollback( STR_ROLLBACK *rollback ) {
sprintf( connid, "%d", rollback->connid );
EXEC SQL ROLLBACK WORK;
rollback->status = SQLCODE;
if ( SQLCODE != 0 ) {
ib_printmsg( "ib_rollback" );
}
}
gpre -e will complain about
(E) e.e:422: expected identifier, encountered ")"
(E) e.e:424: expected identifier, encountered "->"
(E) e.e:428: expected identifier, encountered "->"
> Somewhere in there, there ought to be a test of symbol and anI will take breath and look into this again
> error path. The reason why there isn't is that this code runs
> after the request has been parsed, so all aliases should be in
> the hash table. That's not a reason not to have a test and
> error message, just an explanation why this didn't show up
> before.
>Why does this code then go through gpre when dialect 1 is used?
> Historically, both the embedded language and the qualifiers
> were case sensitive unless the -e switch was used.
> I suspectWill take a look at this.
> that the actual error is somewhere in PAR or SQL, which is upcasing
> aliases and causing the wrong tok_string to be sent to this
> routine. It's probably near whatever it is that handles
> delimited identifiers.
>Hm, I've tested my new version with all available ESQL sources,
> >IMHO, as the user didn't quote the identifiers, they should be
> >considered case insensitive regardless of sql dialect.
>
> IMHO, breaking existing programs by making things more aesthetic
> leads to a certain lack of popularity among the users of those
> existing programs.
so I think the existing user hopefully won't see a difference.
Thanks
Frank
--
"Fascinating creatures, phoenixes. They can carry immensely heavy loads,
their tears have healing powers and they make highly faithful pets."
- J.K. Rowling
http://sourceforge.net/projects/firebird