We recently converted our system to being Unicode compliant. We had set the Unicode flag on just about all programs and objects that needed the flag set and tested them, but when I was doing some routine testing of a table maintenance generator (TMG), I got a dump:
MOVE total TO total_s.
Where TOTAL_S is defined as a line of my table plus some extra fields and TOTAL is a standard field in the interface to the code. During debugging, I could see that TOTAL_S was a nicely formatted work area but TOTAL was a filed with no layout and contained some decimal data (from my table). The decimal data was causing the problem.
The odd thing was that I had a similar TMG (also Unicode compliant) with almost exactly the same code in the same event that was not dumping. It too had decimal data. Comparing the code between the two includes, I could see no difference that would cause a problem. So I debugged the TMG that was working. When I got to the point where the other TMG was dumping, I looked at the structure of TOTAL. It had the same structure as TOTAL_S!
But in both cases, the structure TOTAL_S was generated by the SAP TMG utility. I spent a fair amount of time desk checking, debugging, and staring at the screen, looking for a difference. After some time, I realized that the TMG that had failed was based on a transparent table; the one that worked was based on a view. I didn’t (and still don’t) know why that should make a difference, but I decided to create a new TMG based on a view of the same table.
I created a maintenance view of the table including all fields, created a TMG for the view, added the event and simply copied the code from the failing event to the new one (and changed it to use the new structures).
It worked like a charm.
So the moral is that we should be basing TMGs on maintenance views, not transparent tables. (Actually, I think this is the way it is meant to be, but was not able find anything to this effect in SAP help.)