Как считать поля типа

HOME_X

Добрго дня господа !

Необходимо произвести экспорт данных (txt)
Первая строка это шапка таблицы
Возможно ли считать название поле типа выходной таблицы ?

Code:

            BEGIN OF rcHead,
              ColumnName(100) TYPE C,
            END OF rcHead,
            tbHead LIKE STANDARD TABLE OF rcHead.

rcHead-ColumnName = 'Field1'.
APPEND rcHead TO tbHead.
rcHead-ColumnName = 'Field2'.
APPEND rcHead TO tbHead.
rcHead-ColumnName = 'Field3'.
APPEND rcHead TO tbHead.
CLEAR  rcHead.

CALL FUNCTION 'GUI_DOWNLOAD'
  EXPORTING
    FileName                = 'c:\rr12.txt'
    FileType                = 'DAT'
    Write_Field_Separator   = 'X'
  TABLES
    Data_Tab                = tbView
    FieldNames              = tbHead
  EXCEPTIONS
    File_Write_Error        = 1
    ..............
  OTHERS                    = 22.

Хочу tbHead - заполнить циклом, сославшись на структуру таблицы tbView

Заранее благодарен !

LAT

Не совсем понятно, что Вы планируете делать. Считать названия полей произвольной таблицы?
Если у Вас есть внутренняя таблица tbView, [технические] названия ее полей можно считать, например, так:

Code:

    DATA: ref_table TYPE REF TO cl_abap_tabledescr.
    DATA: ref_struct TYPE REF TO cl_abap_structdescr.
    ref_table ?= cl_abap_typedescr=>describe_by_data( tbView ).
    ref_struct ?= ref_table->get_table_line_type( ).
Таблица ref_struct->components в поле name будет содержать технические имена полей.

HOME_X

LAT написал(а):

Считать названия полей произвольной таблицы?

Совершенно верно - мне необходмо при выводе текста - вывести имена полей

Спасибо получилось !

Code:

            rfTable  TYPE REF TO cl_abap_tabledescr,
            rfStruct TYPE REF TO cl_abap_structdescr,
            rcList   TYPE Abap_Compdescr,
            BEGIN OF rcHead,
              ColumnName(100) TYPE C,
            END OF rcHead,
            tbHead LIKE STANDARD TABLE OF rcHead.

rfTable  ?= cl_abap_typedescr=>describe_by_data( tbView ).
rfStruct ?= rfTable->get_table_line_type( ).
LOOP AT rfStruct->components into rcList.
  rcHead-ColumnName = rcList-Name.
  APPEND rcHead TO tbHead.
ENDLOOP.

А заполнить набор ЗАДАННЫХ полей командой можно ?
INSERT LINES OF rfStruct->components (Name Field1 .....) INTO TABLE tbHead.
Чтобы без цикла обойтись

Code:

LOOP AT rfStruct->components into rcList.
  rcHead-ColumnName = rcList-Name.
  APPEND rcHead TO tbHead.
ENDLOOP.

LAT

HOME_X написал(а):

А заполнить набор ЗАДАННЫХ полей командой можно ?
INSERT LINES OF rfStruct->components (Name Field1 .....) INTO TABLE tbHead.
Чтобы без цикла обойтись

Можно сделать какую-нибудь обертку (макрос/метод/подпрограмму(форму)/ФМ), внутри которой будет тот же цикл

.
ЗЫ. Чем Вам циклы то не угодили? :lol:

HOME_X

LAT написал(а):

Чем Вам циклы то не угодили?

Много кода, признак плохого стиля и недостатка знаний!
Мысль надо выражать лаконично и ОПТИМАЛЬНО ......(ну это не всегда получаеться)

Спасибо за помошь !

Удав

HOME_X написал(а):

Много кода, признак плохого стиля и недостатка знаний!

Кто это вам сказал? :mrgreen:

HOME_X

Удав написал(а):

Кто это вам сказал?

Если Вас на смущает тип пользователя "Начинающий"
считайте это моей цитатой.....

Вы же не переписываете системный функций, а пытаетесь интегрироваться с ними.
(даже если они не оптимальны, хотя и такое бывает....)

Удав

HOME_X написал(а):

Если Вас на смущает тип пользователя "Начинающий"
считайте это моей цитатой.....

[off]Как раз смущает. Безапелляционные высказывания, не подтвержденные опытом, могут сформировать о Вас соответствующее мнение.[/off]

HOME_X

[quote="Удав]
Безапелляционные высказывания...
[/quote]

В смысле - Вы считате что МНОГО пользовательского кода это хорошо ?
Надо пытаться познать системы и дописывать только прикладные моменты

Например - когда надо прилепить третью таблицу, (хотя здесь не ясно, неужели
у ABAP такой слабый SQL - может надо глубже покопать ?)

Удав

HOME_X написал(а):

В смысле - Вы считате что МНОГО пользовательского кода это хорошо ?
Надо пытаться познать системы и дописывать только прикладные моменты

Я считаю, что сначала нужно изучить базовые конструкции языка, а потом делать выводы

Учитывая то, что все прикладные программы в SAP написаны на языке ABAP, то знание самого языка значительно увеличивает шансы "познания системы".
Кроме того, стандартный код SAP не всегда работает хорошо - посмотрите на количество нот. :roll:

HOME_X написал(а):

Например - когда надо прилепить третью таблицу, (хотя здесь не ясно, неужели
у ABAP такой слабый SQL - может надо глубже покопать ?)

Зачем Вам нужен был left join?
С помощью обычного join можно соединить хоть 10 таблиц, хотя практическая выгода от такого соединения априори сомнительна.

Parazit

HOME_X написал(а):

...(хотя здесь не ясно, неужели
у ABAP такой слабый SQL - может надо глубже покопать ?)

SAP реализует некий Open SQL, вероятно по нескольким причинам:
- совместимость разных СУБД;
- интеграция со словарем, навигация по нему, индексация...;
- кластерные таблицы, таблицы пула (собственный обработчик SQL);
- собственные конструкции (for all entries...);
- предварительная обработка запроса (пред-оптимизация, буферизация...);
- и т.д.

В общем куча механизмов, которые надо поддерживать, любое изменение чревато лишними работами. Плюс общая нерасторопность САП в этих вопросах, типа "итак работает".

HOME_X

Хорошему проекту хороший абапер не нужен.
Хорошему абаперу хороший проект неинтересен.
Мы обречены!

Слишком мало поработал чтобы делать выводы - но похоже Вы правы.

Правила форума

Как считать поля типа

Кто сейчас на конференции