>
> There is a limit, though I don't know what it is. It's not just

your user

> savepoints that get accumulated to the total, but also the

internal

> savepoints used by the engine.

Yes I know that.
Who can tell how many savepoints are allowed, and what is the
typical internal use?
I feel however that the problem isn't there - I would get as you
said 'Too many transactions' and I am getting records missing in the
recordset, or insert that don't make in after commit :(

The problem is that when I run step by step instruction, everything
go ok, if I run a transactions it produce different result.

>
>
> >Can I safely read from records I inserted in current transaction

but

> >some levels before possible after few partial commits (savepoints
> >releases)?
>
> I think you are misunderstanding the use of savepoints.

Savepoints don't

> commit anything. They simply flag points in the execution of

statements

> within your transaction to which you can undo changes, without

undoing

> changes that were posted prior to the savepoint. IOW, user

savepoints have

> the effect of nested transactions - atomic blocks of execution

within the

> atomic block that is the enclosing transaction.

I am using them as I would use nested transactions, ie. to
encapsulate atomic operations that consist of several statements
that operate over different tables.
That would be one level, I am facing another levels (hence the need
for nested transaction) where a bulk of atomic operations must be
conducted, and where some of them may fail (then exception,
rollback, go with another operation). Another reason is that it is a
business object layer which operate by creating transactions for
itself as the objects need loading or persisting.

I do think that it is a correct use of nested transactions.

>
> So, typically, your client code will be characterised by branching

logic in

> response to exceptions that occur during the course of the

transaction:

>
> if (ExceptionOccurs) then ROLLBACK TO savp1;
>
> If that's not how you're using savepoints then don't use them.
>
> You can economise on savepoints by reusing the same savepoint

identifier

> once your program logic doesn't need the savepoint any more. By

calling

> SAVEPOINT savp1, you release the existing flag that savp1 is

holding and

> reuse it to flag the current point of execution.

That is not exactly what is written in doc:
"
RELEASE SAVEPOINT <identifier> [ONLY];

Use the RELEASE SAVEPOINT statement to erase savepoint <identifer>
from the transaction context. Unless you specify ONLY clause all
savepoints
established since the savepoint <identifier> are erased too.
"
The way I understand it is that you can release the savepoint to
free the resource. You can't then rollback the atomic operation
embraced by this savepoint, if you can't rollback somethign I call
it 'committed' (although I agree that this might be misguiding). In
such state you can rollback this operation only by rolling back to
earlier savepoint (ie. rolling back transaction of the higher level).

The transaction commit means that all savepoints are relased and
changes are accepted.

>
> >I know I should not update the same record multiple times
> >within the same transaction. I am not doing this, but what could

be

> >the consequences, is it defined as no (if so why there is no
> >exception from Firebird) or it only bails out under some
> >circumstances (what are those if so).
>
> The engine won't stop you from hitting the same row multiple

times, but

> each "hit" on the same row increases the number of internal
> savepoints. When the limit is reached, you will get an exception

("Too

> many savepoints").
>
> Frankly, if your program logic (or your PSQL logic in SPs or

triggers) is

> such that your transaction *needs* to hit the same row more than

once, then

> it's very likely your program logic needs reviewing.

Thats happily not the case ( I have to store data vertically not
horizontally). and hopefully the logic has no need to be changed.

The problem remains however. I believe it is a bug. I'll try to
create reproducable case.

>
> ./hb

thanks Helen

CUIN Kaczy