Subject | Re: How can I skip an Insert ? |
---|---|
Author | Adam |
Post date | 2005-08-11T05:52:24Z |
--- In firebird-support@yahoogroups.com, "yazbeckmona"
<yazbeckmona@y...> wrote:
You seem a little confused about the role of the queries etc.
Firebird will raise an exception if your primary key is not unique.
In other words, you must be supplying a idEmployeur that is already
in the table (a duplicate), and that is against the whole concept of
a primary key. Your application should catch the exception and react
accordingly. It would be very confusing logic to have the database
quietly eat any duplicate data, you would not then know where your
record went. Instead, you now have a mechanism where the database
informs you that the query operation failed, and why it failed. Use
it to your advantage.
In fact, the way you would do input validation in the before insert
trigger would be to raise a custom exception to prevent the insert
from succeeding.
Adam
<yazbeckmona@y...> wrote:
> Hello,would
>
> I would like to add something to my trigger "BeforeInsert" that
> ignore every line that is already in the database. How could I dobefore! I
> that, I have absolutely no idea, I never worked with trigger
> need to NOT insert lines that is already in the database (ofcourse,
> because now I have some primary key duplicate error). (And I don'tit
> want to change my SQL query, because I tried already everything and
> is terribly long.)Triggers do not appear to be what you want.
>
> Here's my trigger with a key generator:
> AS
> BEGIN
> if (NEW.idemployeur IS null) then
> NEW.idEmployeur = GEN_ID(G_EmployeuridEmployeurGen7, 1);
> END
>
> Thank you so much for any help!
You seem a little confused about the role of the queries etc.
Firebird will raise an exception if your primary key is not unique.
In other words, you must be supplying a idEmployeur that is already
in the table (a duplicate), and that is against the whole concept of
a primary key. Your application should catch the exception and react
accordingly. It would be very confusing logic to have the database
quietly eat any duplicate data, you would not then know where your
record went. Instead, you now have a mechanism where the database
informs you that the query operation failed, and why it failed. Use
it to your advantage.
In fact, the way you would do input validation in the before insert
trigger would be to raise a custom exception to prevent the insert
from succeeding.
Adam