При объявлении таблицы, в котором есть поле типа STRING, ругается, что она должна быть плоской структурой.
Как работать с такими таблицами? Только с помощью EXPORT/IMPORT?
Поделитесь кодом плз. кто встречался с таким.

низзя в словарных структурах стринг
чар большой можно

максимум вроде char132

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

можно это делать построчно
таблица
id записи
номер строки
строка

чар можно гораздо больше чем 132, не то 65536, не то что то рядом

Обычно это делают при помощи кластеров, см. конструкцию EXPORT TO DATABASE/IMPORT FROM DATABASE.

Вот это как вариант хранения...
http://help.sap.com/saphelp_nw04/helpda ... ameset.htm

Бинарные данные в таблице можно хранить в таблице БД в полях типа RAW и LRAW. В случае RAW, если не изменяет память, длина до 256, а в случае LRAW - от 256 и выше. Поле LRAW необходимо выровнять на границу 2-х байтов (объявить перед ним поле типа INT2).
Вообще говоря использовать можно довольно длинные поля (32 Кило, например), но вряд ли это разумно. Реально 1024 - 4096 байт
В 4.7 и выше перед записью в таблицу данные можно прессануть при помощи CL_ABAP_GZIP и т.п.

Не совсем понял про выравнивание.
При активации таблицы с LRAW пишет:

Таб. ... для журнала слишком длинная (необх. ключ<250, раздел данн.<16.000

Поле LRAW, разумеется, не может быть ключевым (это с такой длинной-то!). Про выравнивание посмотри, например, в таблице DBTABLOG - поле DATALN там как раз для этого и применяется перед полем типа LRAW.
Ключ сделай обычный: например, если ты собираешься хранить xls-файлы в этой таблице, то ключевыми полями могут быть имя файла и номер записи в таблице

Все создал.
Не могу понять сам механихм записи в LRAW.
Есть интернал табл. с данными в бинарном виде (получены с помощью WS_UPLOAD, в режиме 'BIN'). Причем каждая строка содержит, как я понял один двоичный код. Получается такая табличка, с кол-вом записей тысяч так на 120000.
Неужели объединять строки и разбивать их по длине LRAW?

Из документации к WS_UPLOAD:
"For 'BIN', the table is completely filled line by line. The last line is not necessarily filled completely with file contents. For the reason, the parameter FILELENGTH must also be evaluated."

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

И ещё: "Obsolete. Use class CL_GUI_FRONTEND_SERVICES."

если в дальнейшем предполагается сохраненный файл в таблице выгружать например с ФМ WS_DOWNLOAD, то думаю удобней будет в таблице хранить и размер загруженного файла, раз это бинарный файл

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

а читать/записывать в таблицу с LRAW как и говорили выше нужно с EXPORT TO DATABASE/IMPORT FROM DATABASE, но для этого ваша таблица должна быть определенной структуры http://help.sap.com/saphelp_470/helpdata/ru/fc/eb3c12358411d1829f0000e829fbfe/content.htm
есть для этого и стандарные элементы данных на INDX_*

да и вообще стоит почитать http://help.sap.com/saphelp_470/helpdata/ru/fc/eb3bf8358411d1829f0000e829fbfe/content.htm

удачи!

также для примера можете посмотреть, или даже скопировать в свою таблицу стандартную таблицу INDX, после удалите или замените своими, поля идущие после SRTF2 до CLUSTR

Все сделал, и как показалось в начале все заработало:

В такой последовательности таблица bin_tab ВСЕГДА заполняется нормально. Но после того, как разнес EXPORT и IMPORT в разные места программы, IMPORT в упор перестал заполнять таблицу BIN_TAB. Вернее что-то все-таки делает, т.к. таблица из Inital превращается в 0x32000. Запись в таблице точно есть с таким ID. Не пойму в чем прикол?