IMPACT on moving TABLE(SAPUSER) contained in SYSTEM tablespace to another t

[Former Member]

We have configured DBSPI in our servers. Alerts were received that there are users with default tablespace set as SYSTEM. We have already changed their default tablespace as tools. But the <SID>ADM user still has a table(SAPUSER) contained in SYSTEM tablespace which needs to be moved.

I am not sure about the impact moving this table to another tablespace. Can someone validate if there would be no problem if we move this table to another tablespace?

<b>ECT</b>

~~~~~

USERNAME DEFAULT_TABLESPACE

-

---

-

---

OPS$ORAECT SYSTEM

OPS$ECTADM SYSTEM

TABLESPACE_NAME SEGMENT_NAME SEGMENT_TYPE OWNER

-

---

-

---

-

---

-

---

SYSTEM SAPUSER TABLE OPS$ECTADM

<b>ECP</b>

~~~~~

USERNAME DEFAULT_TABLESPACE

-

---

-

---

OPS$ORAECP SYSTEM

OPS$ECPADM SYSTEM

TABLESPACE_NAME SEGMENT_NAME SEGMENT_TYPE OWNER

-

---

-

---

-

---

-

---

SYSTEM SAPUSER TABLE OPS$ECPADM

[Former Member · Accepted solution]

As such there is no problem until it is accessible by R3trans , but i never tried.

Export the table, move and check it out

regards

subbarao

[Former Member]

concerning table SAPUSER (which did not belong to the SAP Schemauser) read note <a href="http://service.sap.com/sap/support/notes/50088">50088</a>

regards

Peter

[Former Member]

hi Layne,

1. Cannot activate a table in SAP

Syntax error in SDCC, table inconsistency between ABAP Dictionary and the database, transport error 8 during the generation of ABAP Dictionary. When you call Transaction SDCC, a termination occurs due to a putative syntax error because a table is not known or active. When you check this with the ABAP dictionary (SE11), you notice, that the table is active or inactive, however it is not possible to activate it. The activation might terminate with the error message 'Inconsistency between ABAP Dictionary and database'. A check of the affected object also delivers this error.

Solution

Proceed as follows:

• Log on as user DDIC

• Call Transaction SE14

• Enter the affected table name and

• select EDIT

• In the following screen, choose Table -> Reconstruct

• Confirm the execution

• Call Transaction SE11

• Enter the affected table name

• Display

• Activate

If - after you chose EDIT -, the error message occurs that the table only exists on the database, you need to activate the source and the runtime object.

• Call Transaction SE37:

-> Function module 'DD_TABL_ACTM' -> Single test

• Under import parameter MODE, enter the number 12 and under TABNAME the corresponding table name

• -> Execute (F8) -> Export parameter ACT_RESULT must be 0

• Call Transaction SE14 again as described above.

• -> Extras -> Database object -> Check,

as well as

-> Extras -> Runtime object -> Check

inconsistencies should no longer be contained.

If you cannot switch to the EDIT mode in Transaction SE14, which means no modifications are allowed in the customer system, then proceed as follows:

• Call function module 'DD_TABL_ACTM' as described above.

• Then call Transaction SE14 again and verify that the table has been activated.

• As a result, this ensures that the SDCC can be executed.

• The menu options in Transaction SE14 are

-> Extras -> Database object -> Check,

as well as

-> Extras -> Runtime object -> Check

inconsistencies should no longer be contained.

• If this is not the case, open a CSN message under the BC-DWB-DIC-ED component.

Regards.

Kalenthirababu.p

"Reward point it will always encourage me to answer more question"