Table maintenance strategy

[Former Member]

Hi,

I would like to know what are the different strategies followed in different projects for table maintenance.

Background -

We have access to SM30 in our QA system for table maintenance. There have been instances, where we forgot to maintain entries in Prod when we moved the related development to Prod. As a result, the desired functionality did not work in Prod and clients started complaining.

Hence we want to put some restrictions/discipline around table maintenance -

Some thoughts were -

1) Lock SM30 in QA, so that developer can transport entries from Dev, to QA, and Prod since TRs will not be ignored generally

2) For tables, whose entries cannot be transported, but maintained directly in each individual system, the business user should be given a txn code specific for table maintenance of particular table(s).

Request you to share your thoughts and strategies followed in your systems.

Thanks in advance!!

Regards

Deepthi

[naimesh_patel]

It depends of the table purpose.

If your table is useful in some kind of the Customization, than create a table with Customization option and in the Table Maintenance, select the option "Standard Recording routine". This will automatically ask for the request when you change your conttnet in the table.

If you table is purly "Transacational Data" than it would be better to create a maintainence transaction for it. This will helpful to setup the security of the users.

You can very well use the "Authorization Group Assignment" for the table to restrict the security. Follow this path to setup the authorizaiton group for the table:

SE11 > Utilities > Assigne Authorization Group

Regards,

Naimesh Patel

[Former Member]

Hi,

Lock the table Maintainance generator and if what to create entries update the table using a program.

Every time you run this program, it should upload the input text file having records and process it insert, modify, update, delete(what ever process you want) & so you need not go for table maintainance generator

Adithya M

[Former Member]

Hi Deepti,

Depending upon the requirement you have to be clear whether you need the data in the tables or not.

If it is our own data that is required and that should be present in the ztables for the appropriate functionality then better create transport request for the entries and that can be transported to appropriate systems.

One more thing when you are transporting the data through the requests that should be one time data. Because if you want to enter new records or to modify the existing then it is a problem. Every time you have to create a request and you have to transport.

If the data to be changed regularly in the table then better to create a maintenance generator for the table and inform your client regarding that and then can use that properly.

[romanweise]

Hi,

we use a very easy strategy we believe is the only correct one. Everything which ist customizing and can be done in DEV has to be done in DEV and moved through transportation. If someone can change this in QA or even PROD you can throw away QA and DEV as if the system landscape is not equal there is no sense in testing anything there.

Only configuration which has the equivalant of or is due to sap data architecture directly linked to application data is done on each system. The system responsable is instructed and responsible to do this.

Example:

We build a lot of smartforms for application handling. Depending on the target group of the applicant different text modules are used and due to the ongoing development this assignment of target group to text module is put in to a table to be extendable. So if someone adds a new target group which is customizing he has to maintain the new assignments of text blocks in DEV and transport it to QA and PROD.

Another requirement are text blocks for different branches with its adress, assignment also maintained in a table. Due to SAP data architecture the branch is a business partner. So it is application data and the key is different on the systems of the system landscape and so as the creation of the new branch has to be done on each system the table maintanance has to be done on each system.

Best Regards

Roman Weise