Внимание! BUG!

Баг # OE00225722:

65536: maximum number of sub-transactions

Transaction not completely rolled back when more than 65,536 sub-transactions http://knowledgebase.progress.com/articles/Article/000036325

OpenEdge 10.2B05, 10.2B06, 10.2B07, 11.0, 11.1

The fix for this issue is expected to be in the upcoming release 10.2B08.
As of 4/5/2013, release 10.2B08 is scheduled to be released in Q4, 2013 subjected to changes.

Пример такой транзакции:
Код:

do transaction:
  for each table where ...: 
    update table.
  end.
end.

Статья говорит о неполном откате таких транзакций, но ситуация на самом деле хуже. Транзакция с большим числом субтранзакций может успешно завершиться, оставив после себя поврежденные данные, которые будут восприниматься как поврежденные индексы.

Ошибки:

SYSTEM ERROR: Index in for recid could not be deleted. (1422)
**  already exists with . (132)

Причем ошибка 132 может выдаваться для неуникального (!!!) индекса.

На самом деле индексные ключи содержат правильные значения (соответсвующие последним изменениям, сделанным в рамках транзакции), а вот изменения в самих записях могут оказаться потерянными. Из сотен тысяч записей, измененных в рамках большой транзакции, поврежденными могут оказать единицы, а могут и десятки тысяч записей.

Баг исправлен в hotfix'е, который ставится поверх сервис-пака 10.2B07.

Лечение базы

Логично предположить, что для устранения ошибок нужно перестроить индексы в базе. Но это неправильное решение. Индексы будут построены для записей, в которых были потеряны последние изменения. Например, в одном случае баг проявил себя в большой транзакции, в рамках которой создавались новые записи. Как известно оператор CREATE создает "голенькую" запись - копию template записи, в которой все поля имеют значения по умолчанию. Из-за бага в базе появилось огромное число таких "голеньких" записей. Перестройка индексов удалит индексные ключи, содержавшие актуальные значения полей и проиндексирует никому ненужные пустышки. Физическое состояние базы будет корректным, чего, к сожалению, нельзя будет сказать о логической консистентности базы. Удалить пустышки и потом перестроить индексы? Но это потеря "части" транзакции, а транзакция, как известно, по определению не может завершиться лишь частично. Нужно разбираться, есть ли возможность повторно выполнить операцию только для этих записей или нужно откатить все изменения, сделанные в рамках проблемной транзакции. Т.е. лечение базы, поврежденной этим багом, - задача нетривиальная.

На вашем месте я бы в срочном порядке запросил Hot Fix.