Subject | Re: INSERT/SELECT question |
---|---|
Author | Adam |
Post date | 2005-07-20T02:55:35Z |
Myles,
In my experience, the best practice is the 100% reverse.
1. Get the generator value
2. Use it in your query.
So a stored procedure would look something like;
CREATE PROCEDURE TEST
AS
DECLARE VARIABLE MYID INTEGER;
BEGIN
MYID = GEN_ID(GEN_TEST,1);
-- you could now use the value MYID whereever you like,
-- even return it as an output parameter
INSERT INTO TEST (ID, NAME) VALUES (:MYID, 'BLAH');
END
^
If you were doing this from anywhere other than a SP or trigger, then
you would need to select the generator value from a table with a
single record.
SELECT GEN_ID(GEN_TEST, 1)
FROM RDB$DATABASE;
I have been using this approach for so long now that to me it seems
silly to run a query then beg the database to tell you what number it
just assigned to you. Doing it this way has massive benefits if you
store things in a clientdataset (or equivalent), as you don't need to
worry about key substitutions later.
Adam
In my experience, the best practice is the 100% reverse.
1. Get the generator value
2. Use it in your query.
So a stored procedure would look something like;
CREATE PROCEDURE TEST
AS
DECLARE VARIABLE MYID INTEGER;
BEGIN
MYID = GEN_ID(GEN_TEST,1);
-- you could now use the value MYID whereever you like,
-- even return it as an output parameter
INSERT INTO TEST (ID, NAME) VALUES (:MYID, 'BLAH');
END
^
If you were doing this from anywhere other than a SP or trigger, then
you would need to select the generator value from a table with a
single record.
SELECT GEN_ID(GEN_TEST, 1)
FROM RDB$DATABASE;
I have been using this approach for so long now that to me it seems
silly to run a query then beg the database to tell you what number it
just assigned to you. Doing it this way has massive benefits if you
store things in a clientdataset (or equivalent), as you don't need to
worry about key substitutions later.
Adam