Subject | Re: FB 1.5 triggers - appear to work as 'FOR EACH ROW' |
---|---|
Author | Jonathan Hull |
Post date | 2004-07-29T21:39:34Z |
--- In firebird-support@yahoogroups.com, Jacqui Caren
<jacqui.caren@n...> wrote:
The scenario I have is that I want to be aware at the server when data
has been touched by client A, so I can (potentially) synchronise it to
other clients. The data is being changed by clients syncronising
from a local FB store to the server, and I am trying to prevent 2
concurrent client uploads from interleaving the sequence.
I can get around the issue by changing my upload process to request
the next sequence, supplying it as part of the process. However, it
would be ideal at the DB as there is a minor chance that some rogue
sysadmin may decide to do a little direct manipulation of the data
while an upload is occurring.
FYI, the client local data store is FB1.5 embedded, the 'standard'
server if FB1.5 (an excellent DB to anyone who is interested), but we
are also developing to support Oracle, DB2, MSSQL, PostgreSQL, and
(hopefully depending on the opensource license) Ingres II. This is
why syncing is application level, as it needs to support cross vendor
operation and also why the differences between FB and other DB's
become apparent.
Once again, thanks for all the response.
Jono.
<jacqui.caren@n...> wrote:
> > At 05:01 AM 29/07/2004 +0000, you wrote:Thanks everyone for the clarification.
> >
> >>Hi all,
> >>Unless I have missed some doco, it appears that when a trigger is
> >>defined, it fires once for each affected row. Is that correct? If
> >>so, does anyone know a way to get FB to for for all rows affected by
> >>an event (eg update)?
>
> [snip]
>
> I assume that you have existing Oracle row/statement level
> triggers that you wish to migrate to firebird?
>
> Firebird triggers fire per row updated - there are no
> statement level triggers.
>
> Jacqui
The scenario I have is that I want to be aware at the server when data
has been touched by client A, so I can (potentially) synchronise it to
other clients. The data is being changed by clients syncronising
from a local FB store to the server, and I am trying to prevent 2
concurrent client uploads from interleaving the sequence.
I can get around the issue by changing my upload process to request
the next sequence, supplying it as part of the process. However, it
would be ideal at the DB as there is a minor chance that some rogue
sysadmin may decide to do a little direct manipulation of the data
while an upload is occurring.
FYI, the client local data store is FB1.5 embedded, the 'standard'
server if FB1.5 (an excellent DB to anyone who is interested), but we
are also developing to support Oracle, DB2, MSSQL, PostgreSQL, and
(hopefully depending on the opensource license) Ingres II. This is
why syncing is application level, as it needs to support cross vendor
operation and also why the differences between FB and other DB's
become apparent.
Once again, thanks for all the response.
Jono.