SY-UNAME, LARS
Вот что показали полевые испытания : потенциально опасные ситуации появляются только при попытке удаления строк, на которые есть ссылки. В остальных случаях: сортировка, вставка, удаление вновь добавляемых строк, ничего криминального нету.

Ну это то как раз проверяется: if <you_ref> is bound. - то все в порядке

Что-то мне подсказывает, что то, что пытается сделать Long уже реализовано в ABAP и называется SORTED table.
То есть есть стандартая таблица, имеющая плоскую структуру, то есть все строки лежат последовательно в одном куске памяти. На эту стандартную таблицу навешивается SORTED table, хранящая указатели на строки стандартной таблицы. При сортироке двигаются только указатели.
Господа, велосипед изобретаете.
Пойду проверять, если мое предположение верно, то объем памяти под SORTED table должне быть больше объема под стандартную таблицу.

Да, вполне возможно что я погорячился. Во всяком случае фрагмент отработал без проблем ('Ok'). Но из практики вспоминается, что на какие-то проблемы я налетал.

Тоже накатал.

Очень интересны результаты ваших опытов . Поделитесь?

Делюсь. Мои предположения не подтвердились.
Стандартная таблица и SORTED таблица занимают одинаковый объем памяти. HASHED таблица занимает места меньше, примерно на 3%.

Насколько я понял по HELP , ВТ расширяются по 8к, эта цифра конечно варируюется от стратегии выделения памяти. Поэтому может объемы выделенной под STANDART и SORTED различаются, но увидеть это можно только когда их размер приближается к выделяемому Экстенту?

Я только, что задал вопрос на sdn.sap.com по поводу того, в каком виде ВТ размещаются в памяти. Почему-то мне кажется, что они похожи на стандартные контейнеры STL.

Если учитывать только известный факт, что операции вставки и удаления медленные, добавление в конец быстрое и возможен быстрый поиск по индексу, можно предположить, что внутренняя таблица устроена по типу STL VECTOR.