TIMESTAMPL Transport Error

[Former Member]

Hello,

I had to modify a generic datasource to bring in TIMESTAMPL (dec 21) as a pointer for the delta.

It is designated as a timestamp pointer - not numeric or calend day pointer.

Dev tests went fine. Transported to Q environment and am getting the return code 8 in the method execution step. Can anyone please advise because it appears that my view and my datasource both went to Q and are both active. I don't understand what is wrong....

<< Removed >>

Thank you very much,

Lynda

error----

---

>

Post-import method RSA2_DSOURCE_AFTER_IMPORT started for OSOA L, date and time: 20090217144640

The even-numbered length of the DEC field MAPRICE can lead to problems

Field TIMESTAMPL is delta-relevant, but does not exist in the field list

Errors occurred during post-handling RSA2_DSOURCE_AFTER_IMPORT for OSOA L

RSA2_DSOURCE_AFTER_IMPORT belongs to package RSUM

The errors affect the following components:

BC-BW (BW Service API)

Post-import method RSA2_DSOURCE_AFTER_IMPORT completed for OSOA L, date and time: 20090217144642

Post-import methods of change/transport request NGDK900146 completed

Start of subsequent processing ... 20090217144640

End of subsequent processing... 20090217144642

Edited by: Rob Burbank on Feb 17, 2009 4:48 PM

Subject modified and offer of points removed.

[Former Member]

Hello,

I had to modify a generic datasource to bring in TIMESTAMPL (dec 21) as a pointer for the delta.

It is designated as a timestamp pointer - not numeric or calend day pointer.

Dev tests went fine. Transported to Q environment and am getting the return code 8 in the method execution step. Can anyone please advise because it appears that my view and my datasource both went to Q and are both active. I don't understand what is wrong....

<< Removed >>

Thank you very much,

Lynda

error----

---

>

Post-import method RSA2_DSOURCE_AFTER_IMPORT started for OSOA L, date and time: 20090217144640

The even-numbered length of the DEC field MAPRICE can lead to problems

Field TIMESTAMPL is delta-relevant, but does not exist in the field list

Errors occurred during post-handling RSA2_DSOURCE_AFTER_IMPORT for OSOA L

RSA2_DSOURCE_AFTER_IMPORT belongs to package RSUM

The errors affect the following components:

BC-BW (BW Service API)

Post-import method RSA2_DSOURCE_AFTER_IMPORT completed for OSOA L, date and time: 20090217144642

Post-import methods of change/transport request NGDK900146 completed

Start of subsequent processing ... 20090217144640

End of subsequent processing... 20090217144642

Edited by: Rob Burbank on Feb 17, 2009 4:48 PM

Subject modified and offer of points removed.

[former_member156446]

I am not sure.. but it could be some thing related to activation of the transportable objects, make sure where ever you made changes if you have an activation button hit it... or there might be a possiblity that some un wanted objects might have been added into your transport request...

[Former Member]

Thank you for your quick response. I checked the transport again - all it contains it the view and the datasource (active). They are both the correct names of what I want to bring over.

I did not see the extract structure in the transport ZOXDE..... is not there which is a system generated name after you save the RSO2 version.

Maybe that is the problem?

[Former Member]

for some reason the transport did not pick up the extract structure. I looked and it was not sitting in any other transport.

Thank you.

[Former Member]

HI Lynda,

I did get the same error once i transported my Z*Data source request to Quality system.

I did check the Zdata source request in SE09 but it did not collect the VIEW which i did assign to the Zdata source.I did reactivate the Data source along with the VIEW and Extract Stucture and also saved as new request but no use, it is not showing the VIEW under the particular request.

Could you please let me know how did you resolve this issue?

Thanks,

Shailaja

[Former Member]

Hi Shailaja,

Since we were under the gun to get the change into production, we received approval to open the system and I was given SAP_ALL to activate the transfer rules.

However, since then a basis consultant found a note which corrects issues when currency/unit fields are not transferred automatically. This was linked to our problem.

I have similar issues with other transfer rules. Once this note was applied, the transport for the other transfer rules worked....

Please take a look at SAP Note 1124620. Good luck....

Lynda