Modifying SAP Tables directly

[pradiptakumar_mishra]

Hi Friends,

As per SAP, no one should update SAP standard tables diectly. I mean direct modification of data in standard table is not a good practice. But my query is, whether it is been mentioned in any Notes or Best Practice? <removed_by_moderator>

Thanks And Regards

Pradipta Kumar Mishra

Edited by: Julius Bussche on Sep 1, 2008 8:43 AM

[Former Member]

Hi,

Best practice to modify tables is through the concerned T-code or Prgoram only there is not other best practice.

Thanks,

radha.

[Former Member]

Hi,

We should not update Standard SAP tables directly as lot of validations are involved before updating and dependencies can also exist. The Best way is to update through a transaction or a BAPI or a Function Module provided by SAP.

Regards

Nanda Kishore

[Former Member]

See [SAP Note # 7|https://service.sap.com/sap/support/notes/7] and [rule # 2|https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/rulesofEngagement].

Cheers,

Julius

[pradiptakumar_mishra]

Dear Julius,

Thanks for the reply. But the note 7 does not speak anything about modification of data in standard table.

[Former Member]

SAP tables are objects just like SAP programs are objects, etc. They belong to SAP.

SAP provides released functions (e.g. transactions, or function modules - not all of which are released) to update the tables in the way in which SAP's programs have foreseen them to be updated. We are only meant to use the interfaces of these functions, as the programs behind them and the tables can change at any time, or become obsolete.

Whether you modify the SAP program, or modify the table directly, I don't see much difference, and SAP can still choose to cancel your support if they want (to my knowledge).

It's a bit like forums have rules and therefore posts to those forums should be according to those rules as well.... => I deleted your duplicated cross-posting (which is against the rules).

Cheers,

Julius

[pradiptakumar_mishra]

Dear Julius,

Thanks for deleting the post and your valuable reply.

But still I am not able to get my answer. I was expecting to see the SAP note or any document where SAP has documented. Impact of doing the changes are pretty well known in blogs. But where is it mentioned by SAP that customer should not make direct data changes?

Thanks a ton

Pradipta

[Former Member]

> Thanks for deleting the post and your valuable reply.

Based on some of the answers, I don't think you will miss it. Were any of the links posted in it pointing to this thread here?

> But still I am not able to get my answer. I was expecting to see the SAP note or any document where SAP has documented.

I am not sure, but does your license agreement say anything to that affect? I'll check my box-of-tricks and SAP notes tomorrow to see whether there is anything specific about table updates. Perhaps it falls into the grey area between modifying a SAP program and calling an unreleased "for internal user only!" function - depending on which table it is and how big a mess has been created, SAP can elect to cancel support and make changes without any notice anyway.

> Impact of doing the changes are pretty well known in blogs. But where is it mentioned by SAP that customer should not make direct data changes?

Check what your contract states; I will check my box-of-tricks.

Cheers,

Julius

[Former Member]

PS: If you become bored of reading legal or OSS documents and want to read something more technical, and more future oriented...

...then take a look at [An insider's guide to writing ... maintainable, state-of-the-art ABAP programs|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f2dac69e-0e01-0010-e2b6-81c1e8e5ce50].

On page 24, there is a section on packages and a sentence which begins with:

> SAP plans to enhance the access control into the runtime realm...

So, depending on which table you are modifying, and where you are modifying it from, it might no longer be possible anyway...

Perhaps we should have asked this earlier: Which table do you want to modify?

Cheers,

Julius

[pradiptakumar_mishra]

Dear Julius,

The table in question is the one which should not be modified at any cost. It is BSEG. I am not doing or allowing to do the modification but the point is I also need to show whether it is been mentioned any where by SAP. And still now other than sdn and other sites(unofficial sites for SAP) I could not find what I have been looking for. I went through the document you had provided. But the point is still open. Where is it been mentioned by SAP?

Thanks And Regards

Pradipta Kumar Mishra

[Former Member]

> But my query is, whether it is been mentioned in any Notes or Best Practice?

I could not find any note which explicitly states that one should never directly change SAP tables.

What the above document states, is that in a future release access control to objects will be extended to the runtime environment. So program ZTESTUPDATE in package $TEMP cannot access table BSEG directly because it is not in the same nor a nested package of FBAS. ZTESTUPDATE would need to call an interface of FBAS, for example a BAPI, to access data of that package via (released) program interfaces.

> BSEG

I understand that you want a document, and not a horror story: but I knew of a system which not only directly updated the BSEG from customer programs, but had modified the BSEG to add more custom fields to it, amongst several other things to add the custom updates...

I guess as long as it works fine in a unit test, then all is well for a while. But Support Packs and Upgrades were of course out-of-the-question, and eventually it was only possible to logon to the system with a specially created SAP_ALL profile from a higher release system - nothing else worked.

Perhaps someone else knows of a more definitive statement about modifying SAP tables? I will sit on the bench for a while now

Cheers,

Julius

[pradiptakumar_mishra]

Still the mystery prevails. Where is it been mentioned by SAP? I feel we are following a blind alley. Logically it is not a good way to do the updation of standard tables. Anyway the question still remains open.

Thanks

Pradipta

[Former Member]

Purchase this [Book At only cost 25$|http://www.springerlink.com/content/g6vracdfn3jv0q0j/] you will get everything written

Cheers

[ThomasZloch]

> Still the mystery prevails.

Really? This is clear as the brightest daylight, as far as I am concerned.

Or does the operating manual of your car mention that you should hit the brakes before hitting the brick wall?

[Former Member]

I could not even find the word "table" in the preview...

... at least some SAP notes related to # 7 mention the word "table"... :

Cheers,

Julius

[pradiptakumar_mishra]

Good example Thomas. But this is not a car

And I need to know. If you know anything then post a reply.

[Former Member]

I could not even find the word "table" in the preview...

May be you would be able to see all these after buying this

Cheers

[Former Member]

Hi Amit,

You'll have to give me the $25 first to read a book on hardware sizing and expect to find something about the proprietary nature of SAP tables in it...

In return, I will forward to you any emails which I receive from the Central Banks of Nigeria, Burkina Faso and Ghana relating to hitherto unknown bank accounts of mine with a balance > $1m in their database tables...

Of course, if the above searched for official statement is found in that document, then you also get your $25 back + interest...

Cheers,

Julius

[pradiptakumar_mishra]

Thats a pretty cool answer Julius.

[Former Member]

Pradipta,

Is this [Enough|http://sap.ittoolbox.com/groups/technical-functional/sap-basis/table-update-in-se16-200385] to you?

But still searching is on

[pradiptakumar_mishra]

Dear Amit,

I am looking for a document by SAP where it is been stated that we should not update/modify/delete data in standarad tables using our Z - object. I mean it is not to be done without use of BDC/BAPI or standard FM.

As I have already mentioned earlier, it is mentioned all over the Internet about not doing so. But where is it been mentioned by SAP?

Thanks And Regards

Pradipta Kumar Mishra

[JozsefSzikszai]

>

> As I have already mentioned earlier, it is mentioned all over the Internet about not doing so. But where is it been mentioned by SAP?

looks like this has to be officially mentioned by SAP ASAP

[Former Member]

Okay, I found a note which is not directly explicit, but very close...

[SAP Note 908563|https://service.sap.com/sap/support/notes/908563] says that if problems are caused by entries in a table for which there is no standard functionality to have created them... then implement the program changes (SAP as "Mr. Nice Guy" for previous sinners => the existance of which does not limit the scope of [SAP note # 7|https://service.sap.com/sap/support/notes/7]!!

The German text is even clearer than the English (atleast for me it is - although German is not my first language)...

On the other-hand, there are also some very specific problem solutions in some specific SAP notes which have "little Z reports" attached to the solutions... => "vorher wissen, was nachher rauskommt"... so SAP should perhaps not update their own tables either...

(just joking)

In my opinion, this question goes beyond "ABAP Data Transfers" and beyond "ABAP Development" as well... so what do you say (@ Pradipta Kumar Mishra) if we move it to the for some other views and knowledge of documents and problems (I understand that you don't need any sermons about problems or further reasons not to do it)?

"Data transfers" is perhaps too limiting for this topic... let me know about moving the thread.

Cheers,

Julius

PS: "vorher wissen, was nachher rauskommt" (German) = "to know in advance, what the end result will be...." (English)

Edited by: Julius Bussche on Sep 3, 2008 10:43 PM

Checked the spelling. In the Coffee Corner they are very strict...

[pradiptakumar_mishra]

Dear Julius,

I think that might help. Please do the needful.

Thanks

Pradipta

[Former Member]

[Note 592393 - FAQ: Oracle|https://service.sap.com/sap/bc/bsp/spn/sapnotes/index2.htm?numm=592393]

35. What must I do if I cannot use SE16 to make recommended changes in configuration tables?
              For various reasons, it may be necessary to change data in configuration tables (such as DBDIFF, TAORA, IAORA). Due to system and client changeability, this is not possible, especially in live environments. However, you can proceed in one of the following ways:
Change the system changeability (SE06) and/or the client changeability (SCC4) temporarily, so that you can use SE16 to carry out a change.
Check if there is an SM30 maintenance dialog that you can use to maintain the table.
Use database tools (for example, SQLPLUS) to execute the change directly. Caution: Misuse can lead to data loss.

I don't even have a SAP Gui installed at my desk, i work with SQLplus now for years ))

Regards Michael

[Former Member]

Out of curiosity: if you want the address data of users, which table are you using?

Cheers,

Julius

[jurjen_heeck]

> Out of curiosity: if you want the address data of users, which table are you using?

You mean man Is this an interview question?

[matt]

>

> Dear Julius,
>     I think that might help. Please do the needful.
> 
> Thanks 
> Pradipta

I can't believe he really said that.

[Former Member]

>

> looks like this has to be officially mentioned by SAP ASAP 
> 
> 

A related note of the "What is support - What is consulting?" note is [SAP note # 987267|https://service.sap.com/sap/support/notes/987267].

I would like to suggest a version 2 which includes:

-

---

Other Terms

Interview questions, Points system, Thread locked, Thread deleted, Guestification.

...

Additional remarks

The symptoms described above can easily be avoided by using the search. Kindly read [The Rules of Engagement|https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/rulesofEngagement] before posting in the Expert Forums.

-

---

Julius

[Former Member]

Hi,

No one should update the Standard tables directly because SAP is highly integrated ERP. For example if you modify a table content in MM module that might be relted to SD FI Inventory and soo..

IF you directly modify the table in other modules it might not get updated thats the reason it is highly recommended not to update the standard tables

Regards,

Naresh.

[matt]

>

> As per SAP, no one should update SAP standard tables diectly. I mean direct modification of data in standard table is not a good practice. But my query is, whether it is been mentioned in any Notes or Best Practice? <removed_by_moderator>

It's not mentioned in precisely the terms you specify in any SAP official note or good practice document I've ever seen. But then also there's no note that says that if you delete all your backup tapes and then reformat your harddrives, SAP won't help you recover your data.

I like note 415983 about using unreleased function modules potentially leading to a violation of license agreement.

The problem you described is caused by the fact that unreleased function modules were used for a customer development or modification. This is a violation of the software agreements with SAP.
The consequences are as follows:
o   If malfunctions occur after changes have been made to unreleased function modules or if unreleased function modules were used, you are not entitled to any support nor does SAP provide support in these cases.
o   In case of violations, SAP reserves the right to dun the violation of the terms of use and to make a claim for compensation.

There's nothing quite as explicit that I've found about updating tables directly. (Though given the above, I'd be surprised if something similar wasn't found in the licensing legalese) The nearest is note 890379, where it's clear you won't get support for errors caused by "the use of User Exits, Z-Transactions and Modifications to or Custom Developments created in addition to, the Standard SAP code".

So, there's nothing to stop you updating BSEG directly if you want, possibly even it doesn't violate your license. But it will be a custom development that does it, and if it goes horribly wrong, then according to note 890379 you're stuffed. Whether it is bad programming practice or not is utterly irrelevant. Direct changes are carried out at your own risk.

matt

[Former Member]

Hi,

Direct updating of standard tables isn't just a no-no in the SAP world... Do a Google for "referential integrity" which is a basic concept of relational databases. That should give you more of an understanding as to why this sort of practice is bad.

Gareth.

[Former Member]

Moved to the DDIC forum...

[pradiptakumar_mishra]

Thanks for bringing it back to the place from where it roiginated.

[Former Member]

Does SAP has mentioned anywhere that it will revoke the support if the tables are updated directly. Still the question is unanswered

[venkatesan_nagiah]

Hi Pradeep,

You are right that SAP nowhere says that you should not change the database directly.

You can change database directly, but you should take care of data consistency(if technically said) and also you have to take care of data flow (if functionally said). Please check following link for more information:

http://help.sap.com/erp2005_ehp_04/helpdata/EN/41/7af4b6a79e11d1950f0000e82de14a/frameset.htm

enjoy SAP,

Venkat