Subject | Re: converting MSSQL stored procedure to Firebird |
---|---|
Author | tsangccn <tsang_cn@ctimail3.com> |
Post date | 2003-01-29T06:35:39Z |
--- In ib-support@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
CN
> At 10:49 AM 27/01/2003 +0000, you wrote:MyTable
> >Hello,
> >
> >I am converting stored procedure from MSSQL to Firebird,
> >How to define the stored procedure in Firebird for
> >a stored procedure in MSSQL as
> >
> >CREATE PROCEDURE insertRecord
> > @name varchar(10),
> > @id int output
> >AS
> > INSERT INTO myTable (name) values(@name)
> > SELECT @id == @@IDENTITY
> >GO
>
> Assuming you have defined a generator for the identity column of
> (let's call it gen_MyTable_ID) you would do something like this:return
>
> SET TERM ^;
> CREATE PROCEDURE insertRecord (In_Name varchar(10))
> RETURNS (out_ID integer)
> as
> begin
> out_ID = GEN_ID(gen_MyTable_ID, 1);
> INSERT INTO myTable (id, name)
> VALUES (:out_ID, In_Name);
> end ^
> SET TERM ;^
>
> Normally, we don't get the generator value this way. If we need to
> the value to our application, we perform a query to get it *before*we call
> the SP, and pass it as an input parameter.committed;
>
> To read the ID from this stored procedure, you have two options:
> either
>
> 1) EXECUTE it with the statement
> EXECUTE PROCEDURE insertRecord(yourInputString)
>
> and read it from the parameter block returned when the procedure is
>it with
> or
>
> 2) make the procedure return the value as an output set, by calling
> SELECT instead of EXECUTE, viz.need to
>
> SELECT ID FROM insertRecord(yourInputString)
>
> If you need to call this procedure from another procedure, you will
> declare a variable in the top-level procedure, e.g.IBPhoenix
> ...
> DECLARE VARIABLE returned_id integer;
> ...
> begin
> ...
> EXECUTE PROCEDURE insertRecord(yourInputString)
> RETURNING_VALUES(:returned_id);
> ...
> You need to get hold of either the Using Firebird manual (on the
> CD) or the InterBase 6 Language Reference (LangRef.pdf) as there isThank You Helen
> nothing standard about the way different vendors implement their stored
> procedure languages.
>
> heLen
CN