Hello Armel,

I am not quite sure of the structure you are talking about, but if
you have a bunch of records in a single table with some flag denoting
that they are related, then that would potentially be inefficient,
and you should consider normalising your tables to looks something
more like this:

tblgate
(
ID
)

tbl
(
ID
tblgateID
....
)

Then you just run an update on the appropriate tblgate record before
working on the tbl record. As other replies have mentioned, commit is
quicker than rollback. So your query would look something like. You
don't even have to remove your lock as this is done automatically
with a commit.

-- Lock ID 5
update tblgate set id=id where id=5;

-- Work with tbl entries

.....

-- Remove lock
commit;

I use this method in several places, it works like a treat.

Adam

--- In firebird-support@yahoogroups.com, "benedicte_asselin"
<benedicte_asselin@y...> wrote:

>
> hello,
>
> i use locks to make 'group locking' (i.e., i lock
> some master row which is not modified, to protect a set of rows that
> refer to it; one or several rows are modified but locking them
> individually would not work). I commit the transaction if everything
> was OK and it leads to many writes slowing done my stuff.
>
> would it be legal in term of FB inner-structure to have some flag
> telling these are fake updates and that committing them is just
> rollbacking (unless they were really modified by another UPDATE
> call)? and so would it be possible to avoid writes at all in
> embedded/super server architecture?
> I understand that it may involve additional developments but would
> it be possible to implement it that way in FB?
>
> maybe should I find another way to do my locking also, any idea?
>
> Armel