SM30 does not save data

[Former Member]

Hi all,

I have a Z-table which should be maintained using SM30(or function VIEW_MAINTENANCE_CALL). Table has delivery class A-Application table, Display/Maintenance is allowed, and we're maintaining it in the development server, so no restrictions whatsoever for maintaining customizing or such.

The problem is: when I call the overview screen in SM30, change the value of a field (not a key field) and save, the transaction gives the message 'Data saved' but the changes are not really saved in the database.

So I changed the maintenance type in the table maintenance generator from one step to two steps. Result: <b>in the overview screen changes are still not being saved, but if one goes to the detail screen, makes changes there and saves there, the changes are saved to the database.</b> Not very logical I think.

The only reason we could think about is: one of the key fields is a CHAR, 60 positions long, and in the overview screen it is 'shortened' to 30 positions. In the detail screen it's completely visible.

Did anyone else have a similar problem? Any idea what's causing it?

Thanks in advance,

Ioana

[Former Member]

Hi,

Did you activate and adjust database in SE14 after your update in SM30?

Regards,

LM

[Former Member]

Leo,

I don't see how SE14 could help here.

This table was newly created with all its fields, and activated without problems. Then the maintenance dialog for SM30 was created.

And the overview screen in SM30 didn't work from the first time it was created, neither in the one-step processing nor in the two-step processing.

So it's not like fields were added or deleted or changed in the database table, in that case the system asks itself for activation using SE14.

Best regards,

Ioana Virtosu

[former_member404244]

Hi,

activate and adjust database table in SE14 and check....

Regards,

nagaraj

[Former Member]

Nagaraj,

I tried it now - doesn't help - still the same problem.

Best regards,

Ioana

[Former Member]

Hi

<b>Please re-generate the table again by creating a table maintainence again.</b>

This will certainly help.

Please reward suitable points.

Regards

- Atul

[Clemenss]

Hi Ioana,

this is really weird.

Check if there is no customer extension (environment->steps) active. Change the maintenance view in dictionary, use 'expert functions', mark all.

It should work regardless of single or detail screen.

Set a breakpoint at UPDATE statement, check the value for update.

Regards,

Clemens

[Former Member]

Hi Clemens,

It gets weirder.

The UPDATE statement happens in include LSVIMFTX, line 636:

UPDATE (x_header-maintview) FROM TABLE <mod_elem_tab>.

This is where the program does the update on the DB table in both cases (overview screen and detail screen).

(x_header-maintview) contains the name of the Z-table,

<mod_elem_tab> contains the record which should be updated.

For as far as I can see these variables contain identical values in both cases.

But the update fails from overview screen (sy-subrc = 4) and succeeds from detail screen (sy-subrc = 0).

I don't understand what is happening...

Regards,

Ioana

[Former Member]

Hi

Pls delete the existing table maintainence using <b>SE54</b> transaction and then re-create the new table maiantaianence and this will solve the issues, if any.

Hope this will help.

Regards

- Atul

[Former Member]

Hi Atul,

We tried, it didn't help, problem stayed.

Best regards,

Ioana

[Former Member]

Hi

Pls try to make the 2-step screen process to 1 step... the problem will get resolved.

Hope this will help.

Please reward suitable points.

Regards

- Atul

[Former Member]

Loana,

Make it 1 step processing using only one screen. For this you might have to create a new Function Group just to avoid extra coding....

Hope this will clear your problem.

Thanks.

[Former Member]

Tried that, doesn't help, problem stays...

Best regards,

Ioana

[Former Member]

Hi Ioana,

I am seeing the exact same problem. Result: in the overview screen changes are still not being saved, but if one goes to the detail screen, makes changes there and saves there, the changes are saved to the database.

Did you ever find a solution for this problem?

Thanks,

Sanjay

[Former Member]

Sajay,

We found the answer indeed, but it had nothing to do with SM30.

One of our key fields in the table was a numeric field (record number), which was not updated correctly - so not all leading 0's were filled when loading data into the table. We used a load program which loaded from a text file, the field in the text file was 5 positions long, the field in the table was 6 long. And we assumed the conversion would happen automatically but it didn't.

So instead of filling the table field 'record number' with, let's say 000001, it got filled with _00001, and that gave problems in SM30. Pretty hard to find as SM30 didn't show this - we only got to see it in SE16 with the user setting 'SE16 standard list'.

Problem was solved by using the function 'CONVERSION_EXIT_ALPHA_INPUT' in the load program so the table field got its leading 0's correctly. Afterwards there were no problems any more.

Hope this helps.

Greetz,

Ioana

[rahul_negi]

This message was moderated.