Subject | Re: Res: Re: [IBO] (unknown) |
---|---|
Author | Helen Borrie |
Post date | 2004-05-02T21:27:28Z |
At 02:21 PM 2/05/2004 -0300, you wrote:
inserts another row. I couldn't work out why you were doing that.
statement. When you leave that inserted row, it is posted automatically.
BEGIN
if (NEW.TB001_CODIGO_POSICAO is null) then
NEW.TB001_CODIGO_POSICAO = GEN_ID(GENERATOR_POSICAO,1);
END
But you are still going to get the duplicate rows if you continue to follow
up an insert by calling a SP that inserts another row.
If you want the SP to perform the insert, place your EXECUTE PROCEDURE call
into the InsertSQL property of the dataset being updated **at design
time**, with the values parameterised for the SP's input field names (i.e.,
Params).
By that method, the values entered by the user are passed to the SP, rather
than IBO composing its own INSERT statement. Your code should not call
EXECUTE PROCEDURE itself at all.
If you use the same names for the SP params that you used for the dataset's
field names, IBO will take care of the assignments automatically. If you
use different names, you will have to assign the parameter values yourself
at run-time, in the BeforePost. But GeneratorLinks will take care of the
generated key.
Helen
>Dear Helen.Your code seems to insert a row from the dataset and also calls a SP that
>
>Tks for advising me of my horrendously complicated code :/, but I'm doing
>my best changing codes that came from other users...
>I've tried almost everything, but, ok :)))
>
>By the way, your suggestion worked, but, it has something strange.
>After the commit, in the table appears 2 records, instead of 1, like :
>
>Cod Name Description
> 1 Test This is a test
> 2 Test This is a test
>
>They have the same value of name and description, but with different values
>of Cod (1 and 2).
>It is posting 2 records, but why?
inserts another row. I couldn't work out why you were doing that.
>I tried with the stored procedure and with a normal method, like "InsertWhen you place a dataset into dssInsert, IBO creates its own INSERT
>into xxxxx", and no one worked.
statement. When you leave that inserted row, it is posted automatically.
>And when I run the application again, the next code will be 4 and not 3, asThe trigger needs to be changed to
>wished :/
>Sorry to bother you, but, I never used trigger.
>
>Here is my trigger:
>
>CREATE TRIGGER POSICAOTRIGGER1 FOR TB001_POSICAO BEFORE INSERT POSITION 0 AS
>BEGIN
>NEW.TB001_CODIGO_POSICAO = GEN_ID(GENERATOR_POSICAO,1);
>END
>
>I know that here is not a forum of programming, but, I just need this,
>eheheeheh :)
BEGIN
if (NEW.TB001_CODIGO_POSICAO is null) then
NEW.TB001_CODIGO_POSICAO = GEN_ID(GENERATOR_POSICAO,1);
END
But you are still going to get the duplicate rows if you continue to follow
up an insert by calling a SP that inserts another row.
If you want the SP to perform the insert, place your EXECUTE PROCEDURE call
into the InsertSQL property of the dataset being updated **at design
time**, with the values parameterised for the SP's input field names (i.e.,
Params).
By that method, the values entered by the user are passed to the SP, rather
than IBO composing its own INSERT statement. Your code should not call
EXECUTE PROCEDURE itself at all.
If you use the same names for the SP params that you used for the dataset's
field names, IBO will take care of the assignments automatically. If you
use different names, you will have to assign the parameter values yourself
at run-time, in the BeforePost. But GeneratorLinks will take care of the
generated key.
Helen