12-08-2008 8:09 PM
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.
12-08-2008 9:37 PM
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
12-08-2008 8:11 PM
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.
12-08-2008 9:37 PM
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
12-09-2008 2:00 PM
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
12-09-2008 9:59 PM
Hi,
Thanks for the reply,
The tcode is MCAF. He tries to export the data to XXL. The program terminates.......
Thank you,
Sukumar.
12-09-2008 10:16 PM
What does the dump say in tcode ST22? (don't post the whole dump please... only the important parts)
12-09-2008 10:38 PM
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.
12-10-2008 2:56 PM
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.
12-10-2008 3:17 PM
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.
12-10-2008 3:35 PM
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.
12-10-2008 3:58 PM
12-10-2008 6:22 PM
Thanks for the quick reply. No... It is 5 characters in length..
Thank you.
Sukumar.
12-10-2008 6:22 PM
12-10-2008 11:11 PM
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
12-18-2008 3:49 PM
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
03-25-2009 8:43 PM
This requirement was discarded, as the basis guy setup another user id for the person.