oleg_m,

по-моему, я это уже когда-то объяснял, может даже и здесь.

Данные, введённые в рамках одной тр-ции могут оказаться мусором до завершения этой тр-ции только в одном случае -
когда соотв. оператор\блок операторов вызвал ошибку и был откачен соотв. внутренний сейвпойнт.
Ладно, есть второй случай - явный откат пользовательского сейвпойнта :)
Если тебе это подходит - используй.

В любом случае вызывает сомнение сам подход, когда данные многократно вставляются и удаляются из GTT.
Если этого не избежать, можно попробовать добавить индексированное поле с номером экземпляра данных.
Инкрементировать его один раз после DELETE. Даже лучше - вместо DELETE. И добавить в SELECT'ы.

Это про сейчас.

Про будущее - в принципе, можно попробовать физически чистить GTT ON COMMIT DELETE после выполнения
DELETE без WHERE, но такая очистка возможна только когда уже нет активных сейвпойнтов.
На практике это означает, что очистка будет выполена после завершения процедуры верхнего уровня.
Т.е. вряд ли спасёт тебя в данном случае.
Другой вариант - когда будет сделан TRUNCATE, можно подумать о спец обработке GTT в нём. Но это пока что на уровне - только подумать.

hvladПро будущее - в принципе, можно попробовать физически чистить GTT ON COMMIT DELETE после выполнения
DELETE без WHERE, но такая очистка возможна только когда уже нет активных сейвпойнтов.Уточню - когда удаляется тот сейвпойнт, под которым была создана первая запись в GTT.
Это кажется неплохим компромиссом...

kdvhvlad,

тут помог-бы truncate, но его до сих пор нет.
http://docwiki.embarcadero.com/InterBase/2017/en/Truncate_Table А ты это читал ? Внимательно ? :)
Requirements and Constraints
...
It is not possible to truncate system tables, temporary tables , and views.

kdvНо нам-то ИБ не указ, верно? :-)Однозначно.
Но почему бы не перенять хорошие вещи ?
Правда, их практически нет... но они и не публикуют детали, так штааа...