Error on the source system side: “ORA-00903: invalid table name ” (sm21).

[Former Member]

Hello!

We`ve trying to adjust the SLT Server for the real time replication of tables.

And we have a problem, which we can`t solve…

Our source system component characteristics are following:

SAP NetWeaver 7.01

DMIS 2011_1_700 SP6

Oracle 10.2.0.4.0

Our SLT system component characteristics are following:

SAP NetWeaver 7.31

DMIS 2011_1_731 SP06

Oracle 11.2.0.3.0

Our target system component characteristics are following:

SAP NetWeaver 7.31

DMIS 2011_1_731 SP06

HANA DB 1.00.73.00.389160

When we`re trying to replicate a table /BIC/AZC_MV_MT00 (active DSO table) we catch an error on the source system side:  “ORA-00903: invalid table name ” (sm21).

In t-code ST11  in log file dew_w14 we have the following description of error:

Wed Apr  2 16:56:26 2014

*GENER* request remote generation: /1CADMC/SAPLDMC001000000000071.

Client NLS setting (by OCINlsGetInfo(con=1)): 'AMERICAN_AMERICA.UTF16'

Logon as OPS$-user to get SAPSR3's password

Connecting as /@G40 on connection 1 (nls 0) ... (dbsl 720 220612, UNICODE[2])

Starting user session: OCISessionBegin(con=1, usr='/', svc=6e5dd40, srv=6685f60, usr=70d79a0)

Now '/@G40' is connected: con=1, nls=0, session=114, time='2014-04-02 16:56:26'

Got SAPSR3's password from OPS$-user

Disconnecting from connection 1 ...

Closing user session (con=1, svc=6e5dd40, usr=70d79a0)

Disconnected (con=1) from ORACLE.

Connecting as SAPSR3/<pwd>@G40 on connection 1 (nls 0) ... (dbsl 720 220612, UNICODE[2])

Starting user session: OCISessionBegin(con=1, usr='SAPSR3', svc=6e5dd40, srv=6685f60, usr=70d79a0)

Now 'SAPSR3/<pwd>@G40' is connected: con=1, nls=0, session=114, time='2014-04-02 16:56:26'

DB instance G40 is running on sap-bi with ORACLE version 10.2.0.4.0 since JAN 06, 2014, 20:41:18.

con=1, V$NLS_PARAMETERS: NLS_LANG=AMERICAN_AMERICA.UTF8, NLS_NCHAR=UTF8

Nls CharacterSet NationalCharSet EnvHp            ErrHp            ErrBt

   0 UTF16                             AL16UTF16                         6676c10          6682998          6683a78

Connection 1 opened (DBSL handle 1)

OCIStmtExecute() failed with -1=OCI_ERROR

   SQL error 903:

*** ERROR => Error 903 in stmt_fetch() from oci_execute_stmt(), orpc=0

1. bsloci.c 16602]

{root-id=0050562130021EE3AECCC66A817514FB}_{conn-id=00000000000000000000000000000000}_0

*** ERROR => ORA-00903 occurred at SQL stmt (parse error offset=451)

1. bsloci.c    16620]

{root-id=0050562130021EE3AECCC66A817514FB}_{conn-id=00000000000000000000000000000000}_0

Dump statement cache:

sc_p=65dd3d0,no=228,idc_p=(nil),con=1,act=1,slen=498,smax=512,#vars=1,stmt=7062070,table=(

select PLANT , MATERIAL , STOR_LOC , CALDAY , CALMONTH2 , CALYEAR , WEEKDAY1 , CALQUART1 , CALWEEK ,\

CALMONTH , CALQUARTER , HALFYEAR1 from ( select PLANT , MATERIAL , STOR_LOC , CALDAY , CALMONTH2 , \

CALYEAR , WEEKDAY1 , CALQUART1 , CALWEEK , CALMONTH , CALQUARTER , HALFYEAR1 , row_number() over ( o\

rder by PLANT , MATERIAL , STOR_LOC , CALDAY , CALMONTH2 , CALYEAR , WEEKDAY1 , CALQUART1 , CALWEEK \

, CALMONTH , CALQUARTER , HALFYEAR1 ) as rown from /BIC/AZC_MV_MT00 )  WHERE mod( rown, :A0  ) = 0;

Dump statement cache:

sc_p=65dd3d0,no=228,idc_p=(nil),con=1,act=1,slen=498,smax=512,#vars=1,stmt=7062070,table=(

Dumping DBSL stmt. cache:

sc=65dd3d0, scp=65ec560, ups_sc=0000NULL, stp=6f1a928, r_c=0

prep=0, lit=0, nsql=1, lobret_cnt=0, fae_cnt=0, xop=1, dbcnt=0

IN : col_cnt=1, row_max=1, row_xcnt=0, row_pcnt=0, row_i=0, row_total=0,

row_upto=4294967295, row_size=4, vda_max=32, bound=1, itp=67bf650, vda_arr=6f1b050

     lob_cnt=0, lob_max=0, lob_pw_cnt=0, lob_arr=0000NULL, rows_ret=0

OUT: col_cnt=12, row_max=902, row_xcnt=902, row_pcnt=0, row_i=140552804761600, row_total=0,

row_upto=4294967295, row_size=120, vda_max=32, bound=1, itp=66f24e0, vda_arr=6f1b8d0

     lob_cnt=0, lob_max=0, lob_pw_cnt=0, lob_arr=0000NULL, rows_ret=0

select PLANT , MATERIAL , STOR_LOC , CALDAY , CALMONTH2 , CALYEAR , WEEKDAY1 , CALQUART1 , CALWEEK ,\

CALMONTH , CALQUARTER , HALFYEAR1 from ( select PLANT , MATERIAL , STOR_LOC , CALDAY , CALMONTH2 , \

CALYEAR , WEEKDAY1 , CALQUART1 , CALWEEK , CALMONTH , CALQUARTER , HALFYEAR1 , row_number() over ( o\

rder by PLANT , MATERIAL , STOR_LOC , CALDAY , CALMONTH2 , CALYEAR , WEEKDAY1 , CALQUART1 , CALWEEK \

, CALMONTH , CALQUARTER , HALFYEAR1 ) as rown from /BIC/AZC_MV_MT00 )  WHERE mod( rown, :A0  ) = 0;

dbsl err=99=DBSL_ERR_DB -> dbds err=1=DS_SQLERR, dbdsoci.c:1192

*** ERROR => ^^ Ds_fetch() -> err=1=DS_SQLERR

When we test the same SELECT with quotes like:  ……. as rown from  "/BIC/AZC_MV_MT00"  it works correct. And moreover we have no problem in attempts to replicate tables like SWOTOL  without  any  prefixes…

Please help to solve the issue.

[Former Member · Accepted solution]

We`ve opened an incident to SAP and they helped to solve the issue.

The decision is in following:

The incorrect SQL-statement (with missing quotation marks) occurs when

the SLT system tries to calculate access plans with a generated

function module (e.g. /1CADMC/ACS_001000000000073 in source system). The

function module is generated in the SLT system when the runtime

objects are generated. There is an error in the generation of runtime

modules that causes the wrong SQL statement.

Please ensure that the master job of the configuration TEST2 is

stopped (transaction LTRC in the SLT system, tab 'Administartion

Data', button 'Stop Configuration'), then implement the OSS notes

1990054 and 1992138 in the SLT system.

After you have implemented the notes, use transaction LTRC again and

restart the master job. Then go to tab 'Table Overview', click on

button 'Data Provisioning' and stop the load/replication of the tables

/BI0/AAPO_DS0500, /BI0/AAPO_DS0540, /BIC/AZC_MV_MT00.

When the three tables do not occur in the table overview anymore,

click again on button 'Data Provisioning' and (re)start the

replication of the three tables. The system will generate the runtime

objects again (this time without the incorrect SQL statement), and the

error should not occur anymore when the acces plan is calculated