Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Exportto excel in tcode MCAF results in program termination for only 1 user

former_member193771
Contributor
0 Kudos

Hi,

The user is trying to export data from MCAF into a local file. This action results in program termination, its only for his user id. It works for all the user ids the basis guys had a look at it and they said everthing is ok on the authorization side. Im confused, please let me know...

Thanks,

Sukumar.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hmmm....

How is the user downloading the data? (SE16? Query? Custom program? etc).

Which program context and reason does ST22 show for the termination?

That a copy of the ID does not cause a problem, but a rename does... would tend to indicate that something is being "set" when the user runs the transaction which is user specific, and therefore when you rename the ID (which is dangerous anyway) this connection is lost. This could be caused by a GET/SET parameter (PID).

Just guessing,

Julius

15 REPLIES 15

former_member193771
Contributor
0 Kudos

Hi,

The basis guy created a copy of the users id and the same transaction worked for the copy, but when we actually rename the id back to his id after deleting the other one, the same error. So this is something weird...

Thanks,

Sukumar.

Former Member
0 Kudos

Hmmm....

How is the user downloading the data? (SE16? Query? Custom program? etc).

Which program context and reason does ST22 show for the termination?

That a copy of the ID does not cause a problem, but a rename does... would tend to indicate that something is being "set" when the user runs the transaction which is user specific, and therefore when you rename the ID (which is dangerous anyway) this connection is lost. This could be caused by a GET/SET parameter (PID).

Just guessing,

Julius

0 Kudos

right on the spot Julius,

I had similar problems they were solved by comparing the user parameters and making them equal to the user NOT having the problem

0 Kudos

Hi,

Thanks for the reply,

The tcode is MCAF. He tries to export the data to XXL. The program terminates.......

Thank you,

Sukumar.

0 Kudos

What does the dump say in tcode ST22? (don't post the whole dump please... only the important parts)

0 Kudos

Thanks for the quick reply!!!

Error analysis

The system tried to access field "OE_OBJEKTTEXT" with type "C" and length

60 in the current program "RMCY9110 " using offset 71.

Partial field access is not allowed with an offset specification that is

larger than actual field length.

How to correct the error

Make the offset smaller with which you want to access the field.

If the error occurred in an ABAP program of your own or an SAP program

that you modified, try to correct it.

If the error occurred in a non-modified SAP program, you may be

able to find a solution in the SAP note system.

If you have access to the note system yourself, use the following

search criteria:

"DATA_OFFSET_TOO_LARGE"

"RMCY9110 " bzw. "RMCS0F0O "

"OBJEKTTEXT_ERMITTELN"

Thanks,

Sukumar.

0 Kudos

Hi,

The user parameters were compared very closely. We removed everything for this particular user, still it does not work in prod, works in QA though...

Thanks,

Sukumar.

0 Kudos

Hi,

We re on SAP 4.6B. Further.... user XXX has the problem, and he is the only user to have this problem.

If I copy user XXX to YYY, then user YYY does not have this problem. If we delete XXX and then rename YYY to XXX, then user XXX still has the same problem....

Thanks,

Sukumar.

0 Kudos

Only thing i can think of i a lock in a table for the userid.

possible solution:

Trace the report and list all effected tables.

open alle tables in the trace in SE16 and see if there is a uid entry. If so look for the uid with the problem and try to delelte the uid in the table.

0 Kudos

Is the name of the user ID longer than 10 characters by any chance?

0 Kudos

Thanks for the quick reply. No... It is 5 characters in length..

Thank you.

Sukumar.

0 Kudos

We are on SAP 4.6B.....

0 Kudos

I would need to rack my brain to find access to a 46B system again, assuming that makes the difference.

Way back when, the system used a lot of background scheduling. Sometimes, you needed to be able to schedule jobs in your own name to be able to create the job step at all.

What it might be is that the job name already exists (from your first test) but when you rename the user, then trying to use the same job for a step with a different sy-uname imported is checking (correctly) that A is not scheduling steps as B.

I remember having seen something like this in the coding of SU01, now that you mention it.

Renaming users is an all round bad idea in SAP for many reasons. It is too easy to make mistakes.

There have been a number of threads about these symptoms already. Pl ease open a customer note with SAP to report your concerns (even although your release is out of mainstream support, it is still valid).

Cheers,

Julius

0 Kudos

Hi,

The basis guy here thought that, It is not worth the effort of a single user. So he created another user id. Im a workflow guy.

Thanks for all your suggesions though....

Sukumar

former_member193771
Contributor
0 Kudos

This requirement was discarded, as the basis guy setup another user id for the person.