Submitted by: Boltik Evgeny (bolt)

Is related to CORE5142

Test case:

CREATE TABLE Q (F1 INT);

CREATE OR ALTER TRIGGER Q_AD FOR Q
ACTIVE AFTER DELETE POSITION 0
AS
BEGIN
DELETE FROM Q;
END

COMMIT;

INSERT INTO Q (F1) VALUES (1);
INSERT INTO Q (F1) VALUES (2);
INSERT INTO Q (F1) VALUES (3);
INSERT INTO Q (F1) VALUES (4);

COMMIT;

DELETE FROM Q;
-- ERROR:
-- no current record for fetch operation.
-- At trigger 'Q_AD' line: 5, col: 3
-- At trigger 'Q_AD' line: 5, col: 3.
-- this is more or less expected (or at least known about), see CORE5142

DELETE FROM Q;
-- ERROR:
-- no current record for fetch operation.
-- At trigger 'Q_AD' line: 5, col: 3.
-- error is now raised at the first level of trigger recursion

DELETE FROM Q;
-- ERROR:
-- no current record for fetch operation.
-- error is now raised by the outer DELETE itself

In more complex examples the final execution happens without errors at all. Intermediate ROLLBACKs between DELETEs don't change anything. Reconnect returns everything to its original state, i.e. problem is not persistent.

Happens only after "no current record for fetch operation" error is raised. Related to stable cursors. Happens either for re-executions of prepared statements or if error is raised inside a trigger or stored procedure (as their requests are reused).

Commits: f13942b f9c3f81

====== Test Details ======

Previous .fbt was deleted.
See test for CORE5142.