Subject | Re: [firebird-support] Re: Checking periods don't overlap |
---|---|
Author | Lester Caine |
Post date | 2004-06-14T15:08:52Z |
johnsparrowuk wrote:
and the commit of the first check happens so that the second user sees
the committed data and can't then save their conflicting change. I can
see what you are getting at though, and a flag of the free space would
solve the problem.
All time segments are in the database - even the gaps. Select the one
you want to insert into, and write back the one, two or three segments
that are created. Which ever gets in first will win, and the second
attempt can be retried against the new free space. The start and stop
times of the free space are then automatically flagged, and you could
flag the free space with the user_id of the person who accessed it first?
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
> You don't *need* to use a trigger, but using your solution has theMine don't. The select to check is a new clean read of committed data,
> same problem - if there is an uncommitted record in another
> transaction (with an overlapping time-period), you won't see it, and
> it won't see you.
>
> You'll both commit fine. And then you've got a problem.
and the commit of the first check happens so that the second user sees
the committed data and can't then save their conflicting change. I can
see what you are getting at though, and a flag of the free space would
solve the problem.
All time segments are in the database - even the gaps. Select the one
you want to insert into, and write back the one, two or three segments
that are created. Which ever gets in first will win, and the second
attempt can be retried against the new free space. The start and stop
times of the free space are then automatically flagged, and you could
flag the free space with the user_id of the person who accessed it first?
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services