> > With this second method, you'd probably need to beware race conditions. If
> > another process inserts a record into mytable after you do but before you
> > call currval(), then you'll get the wrong value.
> >
> > Not an issue if you've only got one process accessing the table - probably
> > is one if you have two or more.
>
> I don't think that's true the currval belongs to the process (as it were)
> so that what happens is that currval remains unchanged by inserts by other
> processes.
>
> nextval however is 'affected' meaning that nextval won't just return
> curval+1, it returns whatever the next sequence item is taking into
> account the increasses caused by other processes.
>
> at least I seem to remember that from previous postings... any seconders?
currval always gives you the most recent sequence value returned by your
own back-end, so that it is not affected by waht other processes do.
With nextval it also depends on what cache size you chose. If youchose
1, the default, nextval is directly affected by whether other processes
have doena nextval. If the caches is larger this is not necessarily the
case.
Adriaan
