maintenance view settings

[Former Member]

Good morning. I created a maintenance view for one of our custom tables, and we're having some problems with it. The table was originally set under "Delivery and Maintenance" as delivery class C (customizing table), with "Display/Maintenance Allowed". The maintenance view works just fine in our development client. So we transported the view to our quality client. But when we tried to access the view there via transaction SM31, we got the message "Client 215 has status 'not modifiable'". We were told by our security personnel that this was because we had the table as delivery class C. So we changed it to delivery class A. But we are still getting the same message.

In table T000, our quality clients have the setting "No changes to repository and cross-client customizing objects". Is this what is causing the error message? Or is there some other setting that either security or basis needs to change? Thanks for your help.

- April King

[Former Member]

Client 215 has status 'not modifiable'

the above message will appear when you dont have the change access to maintain that table,

In Quality client may be you are not allowed to change the Maintenance , chk your profiles

You can check with some z maintence in Production also , it will display the same message

[Former Member]

There is another custom table, though, that also has a maintenance view. It is delivery class A with maintenance allowed, and I can access the maintenance view of that table in development and quality clients. Do you know of any reasons why I would be able to use the maintenance view of one custom table in a client but not the maintenance view of a different custom table in the same client? Both tables now have the same delivery class and are client dependent. I'm not getting any authorization errors (I checked SU53).

- April

[Former Member]

Delete the table maintenance and regenerate.

[Former Member]

Thanks. I knew you had to delete and regenerate the view when you added or removed fields from a table, but I didn't realize it was necessary for this type of change as well.

[Former Member]

The reason for that is when you define a table as customizing table, you will automatically see that it asks for a transport whenever you create or change data whereas with the other types it doesn't automatically ask for that. That is why you will need to delete the old maintenance and recreate it because when you originally generated it, it includes the piece of code that will require a transport pop-up to come up whenever you add/change data.

[Former Member]

Hi,

You do not have the Proper Authrizations in the Quality system to Make the changes or Insert the new Entries from SM30, you need get the Correct profile as well as Authrozation object. just Ask the basis people to add your User name to those profile which will have the Change access in Quality System

Regards

Sudheer

[Former Member]

Is your table cross-client (meaning does it have MANDT as a key field or not)? If it is client-independent (no MANDT key field), then you cannot maintain them in quality or production environments. Quality and production systems are set to be 'not modifiable', that is not the fault.

If you have your table set as 'C', you should then maintain it in your development environment always which will automatically force you to create a transport request. You will always maintain the data in development and move it using transports.