*_FIELDCATALOG_MERGE
이거 이제 그만좀
72자 제한은 너무하잖아 2021년인데
FCAT MERGE FM들 (REUSE, K어쩌구 등)은 크게 두 가지 문제가 있다.
1. ITAB 구조변경시 버퍼 클리어 안됨
2. 72자 제한
안쓰게 된지 벌써 1년은 된 것 같고, 별 문제 없이 사용중이니 더 편한 방법을 소개한다.
아니.. 솔직히 더 편한지는 모르겠다.
다만 위 오류에 상관없이 실행이 가능하다는 점이 돋보인다.
어차피 복붙이니 안힘든건 매한가지인거 같기도 하고.
다음은 예시
DATA: BEGIN OF GT_COL OCCURS 0.
INCLUDE TYPE MKPF.
DATA: MATNR LIKE MSEG-MATNR,
AUFNR LIKE MSEG-AUFNR,
END OF GT_COL.
DATA: LO_STR TYPE REF TO CL_ABAP_STRUCTDESCR.
LO_STR ?= CL_ABAP_STRUCTDESCR=>DESCRIBE_BY_DATA( GT_COL ).
DATA(LT_DFIES) = CL_SALV_DATA_DESCR=>READ_STRUCTDESCR( LO_STR ).
DATA(LT_FCAT) = CORRESPONDING LVC_T_FCAT( LT_DFIES MAPPING REF_TABLE = REFTABLE
REF_FIELD = REFFIELD ).
CALL FUNCTION 'LVC_FIELDCAT_COMPLETE'
CHANGING
CT_FIELDCAT = LT_FCAT.
구성이 꽤 알찬 것을 볼 수 있다. 다만 직접 선언한 필드의 경우, TABNAME이 비어있다.
이후에 KEY, REF_TABLE, REF_FIELD 정도만 채워주고 나면,
일반적인 경우 굳이 속성을 더 건드린 적은 없는 것 같다.
뽀너스로 MERGE FM가 버퍼에 등록되어 필드를 변경해도 반영이 안될 때
아래 소스를 돌려주면 버퍼를 클리어한다.
어디 몰래 달아두자(...)
DATA: L_MEMORY_ID_CLEAR TYPE STRING,
L_MEMORY_ID_HASH TYPE HASH160.
CLEAR : L_MEMORY_ID_CLEAR.
CONCATENATE '프로그램명' 'GS_LIST_FCAT_MERGE' INTO L_MEMORY_ID_CLEAR.
CALL FUNCTION 'CALCULATE_HASH_FOR_CHAR'
EXPORTING
DATA = L_MEMORY_ID_CLEAR
IMPORTING
HASH = L_MEMORY_ID_HASH
EXCEPTIONS
OTHERS = 4.
FREE MEMORY ID L_MEMORY_ID_HASH.
그리고 굳이 72자 제한인건
내부에서 호출하는 READ REPORT 구문에서 프로그램이 퍼지는 것으로 보인다.
사용되는 인터널테이블 라인이 CHAR72로 되어 있어서 그보다 긴 소스가 들어오려 하면 펑!
