IMPORT x TO y FROM DATABASE dbtab(ar) ID Key

[achraf_smaali]

Hi Experts,

I'm upgrading me version of SAP to ECC6, so when I execute a program an error triggered when importing object "ADDONS".

I got this message :

An exception occurred that is explained in detail below.

The exception, which is assigned to class 'CX_SY_IMPORT_MIS not caught in procedure "ISU_BILLPRINT_INTERVALS_CLOSED"

"(FUNCTION)", no by a RAISING clause.

Since the caller of the procedure could not have anticipate exception would occur, the current program is terminated.

The reason for the exception is: When attempting to import data, the structure of the complex object h1 _ "ADDONS"_h1 was not compatible with the target object. The error occurred with component no. 0.

When I launch the ABAP Debugger, It stops at this part of code :

* Read basics and addons from database
  import basics to l_basics
         addons to RED_PARAMS
         from database rfdt(kk) id l_runkey.

I realised a small research on the net to get an idea about The ABAP statement IMPORT x TO y FROM DATABASE dbtab(ar) ID Key, I found this :

TABLES INDX.
DATA: INDXKEY LIKE INDX-SRTFD,F1(4),
F2 TYPE P,BEGIN OF TAB3 OCCURS 10, CONT(4),
END OF TAB3.
INDXKEY = 'INDXKEY'.
IMPORT F1 F2 TAB3 FROM DATABASE INDX(ST) ID INDXKEY.

But I didn't understand what's ST?

So can any guru tell me what's the meaning of ST, and how can I resolve the above problem.

I know that my problem consists on a difference between the structure of ADDONS and RED_PARAMS.

NB: The structure of RED_PARAMS is as follows :

R_VKONT

R_PARTNER

R_PORTION

R_ABRVORG

R_FIKEY

R_ERGRD

R_DRUCKDAT

SIMU

INVOICED

TOBRELSD

GENPARA

TEST_PR

XSTR_PRINTPAR

EXLOG

PS: I don't have access to ADDONS (Which I don't know what is it?!!!)

Regard

SMAALI Achraf

[tamas_hoznek]

ST is what goes into the field RELID when using EXPORT with a cluster table (such as INDX - or RFDT, for that matter). In your code, that would be KK.

If you don't know how the EXPORTed data cluster looked like, it is hard to guess what's wrong and how RED_PARAMS should be defined.

[Former Member]

ST is the memory ID . if u see the database table RFDT .. ST will be stored into KEY field RELID. and the memory ID will be stored into the field SRTFD . The dump is caused due to the data type mismatch . u need to find from where this is exported to rectify this dump.

[Former Member]

In the example, the ST would be set by the program that did the export to the INDX-like table. I see you've found some information; as search on SDN/SCN for "shared objects" might give you even more information.

For the problem, what I would do is try to find the program that does the EXPORT part of this shared objects usage. There you will find the values that were assigned the export along with the ADDONS structure (or table) definition.

[achraf_smaali]

I can't find the value KK in the field RELID of the table RFDT.

But the exception is triggered in the Function Module "ISU_BILLPRINT_INTERVALS_CLOSED" which is a standard FM,

so can any one tell me where the statement import the ADDONS.

Or you can suggest another FM which can do the same job.

[tamas_hoznek]

Hm... If you don't have any data with RELID as KK, then how do you get an error when importing a data cluster with said RELID? No data, no IMPORT -> no data structure incompatibility...

Anyway... That function module belongs to the Utilities industry solution. So KK as RELID is probably specific to that IS.

If you have access to the system you are upgrading from, try to search for RFDT there via the where-used list and see if you can find a piece of code doing an export with RELID KK. Then you should have the structure of ADDONS.

You can also try to create an OSS message and ask for SAP support seeing that the problem is with a standard FM.

[achraf_smaali]

It as a standard error which due to upgrading the version of my SAP so It's not my problem anyway we did the Call OSS

[NTeunckens]

We've encountered a very similar issue in an upgrade scenario. The same error message regarding missing or incorrect ADDONS ...

Our issue was an inconsistency when passing 'old' parameters / program variants to 'mass activities' programs for transactions such as 'FPSCHEDULER' and/or 'EL16' ...

We did also open an OSSmsg to raise awareness with SAP.

However, a simple workaround/test would be to identify the related programs that are affected by the issue. The variants or relevant setting to these 'mass activities' programs are stored in the cluster table (such as 'DBTAB' or in our case 'RFDT') mentioned in the shortdump message.

Due to upgrade-changes our stored input did not match the new structure for the upgrade environment.

When you've identified the relevant program and their variants / parameters, simply recreate the variant or create a new one, so the cluster table stores a new record in the cluster table ...

In our scenario, we were able to surpass the shortdump.

This might be only one of few methods to solve related issues. In any case, this simple test can prove to be a good addition for your analysis when posting an OSS.