Subject | Re: [IB-Architect] SQL Scripts |
---|---|
Author | Marco Lauria |
Post date | 2001-12-07T22:45:26Z |
At 17.51 07/12/2001 +0100, you wrote:
so for all the commands except CONNECT, DROP AND CREATE.
I don't include COMMIT or ROLL BACK as these regards the server
and not the client.
Also I am thinking now about nested transactions, but
FB doesn't support them...
and it is another story.
I answer also to a message of Jim regarding this topic:
For the error handling I think it's not a problem,
use the absolute line from the beginning of the script can be the right choice.
For the prepare....
can't we prepare the entire script?
I think that with a similar function we can also enable the declaration
of the variables or the loops typical of the SP in DSQL....
My two cents,
Marco
> > I have found in the past that scripts which work using one tool (ISQL,It should be on the server, for the command typical of the server
> > IBConsole etc) fail on another. Making the engine perform this task
> > would stop errors like this occuring. (A similar and related problem
> > occurs with metadata extraction tools.)
>
>So, you want standard, built-in, script interpreter.
>Perhaps as part of gds32 ?
>(It can't be on the server - imagine commands like COMMIT, CONNECT,
>DROP DATABASE, INSERT <script.sql>, ...)
so for all the commands except CONNECT, DROP AND CREATE.
I don't include COMMIT or ROLL BACK as these regards the server
and not the client.
Also I am thinking now about nested transactions, but
FB doesn't support them...
and it is another story.
I answer also to a message of Jim regarding this topic:
For the error handling I think it's not a problem,
use the absolute line from the beginning of the script can be the right choice.
For the prepare....
can't we prepare the entire script?
I think that with a similar function we can also enable the declaration
of the variables or the loops typical of the SP in DSQL....
My two cents,
Marco