0
votes

Background:

I have several tables that are connected for maintenance in a view cluster (SE54). Each of these tables have the standard Created/Changed By/On fields. For created data updating the fields are easy, and I use event 05 (On Create) in the Table Maintenance generator. For defaulting the changing fields it's a little bit more involved. I have to use event 01 (Before Save), and then update the tables TOTAL[] and EXTRACT[] with the field values as needed.

When maintaining the table in SM30, the format of TOTAL[] and EXTRACT[] is the same as the view I'm maintaining with an additional flag to identify what type of change is made (update/create/delete)

However, when maintaining in SM54 (which is the business requirement), the format of TOTAL[] and EXTRACT[] is just an internal table of character lines.

Problem:

I can figure out what the type of the table that is being edited is. But when I try to move the character line to the type line I get the following run-time errors: (Depending on how I try to move/assign it)

ASSIGN_BASE_TOO_SHORT
UC_OBJECTS_NOT_CONVERTIBLE
UC_OBJECTS_NOT_CHAR

All my structures are in the following format:

*several generic (flat) types
CREATED    TYPE TMSTMP,  "not a flat type
CHANGED    TYPE TMSTMP,  "not a flat type
CREATED_BY TYPE ERNAM,
CHANGED_BY TYPE AENAM,

The root of the problem is that the two timestamp fields are not flat types. I can see in the character line, that the timestamps are represented by 8 Characters.

Edit: Only after finding the solution could I identify the Length(8) field as packed.

I have tried the following in vain:

"try the entire structure - which would be ideal
assign ls_table_line to <fs_of_the_correct_type> casting.  

"try isolating just the timestamp field(s)
assign <just_the_8char_representation> to <fs_of_type_tmpstmp> casting.

I've tried a few other variations on the "single field only" option with no luck.

Any ideas how I can cast from the Character type to type TMSTMP and then back again in order to update the internal table values?

1
Is there any reason you chose to use timestamps for the database fields instead of the widely used separate date/time fields (ERDAT/ERTIM, ...)? - vwegert
@vwegert None other than I was dictated the design :(. ERDAT/ERTIM would have been great as they are flat structures which in return makes this whole thing go away. We do interface with a Java System, but I doubt that there is any real technical reason to use timestamps (it's not even a multiple-timezone system). - Esti

1 Answers

3
votes

I've found that the following works:

In stead of using:

field-symbols: <structure> type ty_mystructure,
               <changed>   type tmstmp.

assign gv_sapsingle_line to <structure> casting. "causes a runtime error
assign gv_sap_p8_field   to <changed> casting.   "ditto

I used this:

field-symbols: <structure> type any,
               <changed>   type any.

assign gv_sapsingle_line to <structure> casting type ty_mystructure.
assign gv_sap_p8_field   to <changed> casting type ty_tmstmp.   

For some reason it didn't like that I predefined the field symbols.

I find that odd as the documentation states the following:

Casting with an Implicit Type Declaration Provided the field symbol is either fully typed or has one of the generic built-in ABAP types – C, N, P, or X – you can use the following statement:

ASSIGN ... TO <FS> CASTING.

When the system accesses the field symbol, the content of the assigned data object is interpreted as if it had the same type as the field symbol.

I can only assume that my structure wasn't compatible (due to the P8 -> TMSTMP conversion)

The length and alignment of the data object must be compatible with the field symbol type. Otherwise the system returns a runtime error. If the type of either the field symbol or the data object is – or contains – a string, reference type, or internal table, the type and position of these components must match exactly. Otherwise, a runtime error occurs.