Raise Exception in IW31 Transaction

Hi All,
I have a situation that when the user executes IW31 transation, he gets a runtime error RAISE_EXCEPTION.
The exception is raised from the program LCUKOF1E line 88.
Please help me in analysing this dump. Any inputs on this dump will be helpful.
Thanks in advance,
Raj

Yes, I have the details of the dump with me. But i need to know why the dump has occured and what are the possible solution to rectify this dump.
Thanks in advance,
Raj

Similar Messages

Crm_ic created raised exception

Hello,
I tried to run tcode crm_ic but I got following error message from the internet explorer:
The following error text was processed in the system CRO : Exception
condition "COMMUNICATION_ERROR" raised.
The error occurred on the application server sap1770_CRO_01 and in the
work process 0 .
The termination type was: RABAX_STATE
The ABAP call stack was:
Method: CREATE_SESSION of program CL_SAM_BSP_SESSION_LAUNCHER===CP
Method: START_WORKER_SESSION of program CL_ICWC_SESSION_REGISTRY======CPMethod: ONCREATE of program CLO23UTXK1DHIM8WX0QZD2TBW2KZ9CP
Method: %_ONCREATE of program CL_O23UTXK1DHIM8WX0QZD2TBW2KZ9CP
Method: DO_INIT of program CL_BSP_PAGE===================CP
Method: GET_PAGE_CONTEXT_CURRENT of program
CL_BSP_CONTEXT================CP
Method: ON_REQUEST_ENTER of program CL_BSP_RUNTIME================CP
Method: ON_REQUEST of program CL_BSP_RUNTIME================CP
Method: IF_HTTP_EXTENSION~HANDLE_REQUEST of program
CL_HTTP_EXT_BSP===============CP
Method: EXECUTE_REQUEST of program CL_HTTP_SERVER================CP
Below is the abap dump message:
Runtime Errors RAISE_EXCEPTION
Date and Time 14.05.2007 04:05:51
Short text
Exception condition "COMMUNICATION_ERROR" raised.
What happened?
The current ABAP/4 program encountered an unexpected
situation.
What can you do?
Note down which actions and inputs caused the error.
To process the problem further, contact you SAP system
administrator.
Using Transaction ST22 for ABAP Dump Analysis, you can look
at and manage termination messages, and you can also
keep them for a long time.
Error analysis
A RAISE statement in the program "CL_SAM_BSP_SESSION_LAUNCHER===CP" raised the
exception
condition "COMMUNICATION_ERROR".
Since the exception was not intercepted by a superior
program, processing was terminated.
Short description of exception condition:
For detailed documentation of the exception condition, use
Transaction SE37 (Function Library). You can take the called
function module from the display of active calls.
How to correct the error
If the error occures in a non-modified SAP program, you may be able to
find an interim solution in an SAP Note.
If you have access to SAP Notes, carry out a search with the following
keywords:
"RAISE_EXCEPTION" " "
"CL_SAM_BSP_SESSION_LAUNCHER===CP" or "CL_SAM_BSP_SESSION_LAUNCHER===CM002"
"CREATE_SESSION"
or
"CL_SAM_BSP_SESSION_LAUNCHER===CP" "COMMUNICATION_ERROR"
or
"SAPMHTTP " "COMMUNICATION_ERROR"
If you cannot solve the problem yourself and want to send an error
notification to SAP, include the following information:
1. The description of the current problem (short dump)
To save the description, choose "System->List->Save->Local File
(Unconverted)".
2. Corresponding system log
Display the system log by calling transaction SM21.
Restrict the time interval to 10 minutes before and five minutes
after the short dump. Then choose "System->List->Save->Local File
(Unconverted)".
3. If the problem occurs in a problem of your own or a modified SAP
program: The source code of the program
In the editor, choose "Utilities->More
Utilities->Upload/Download->Download".
4. Details about the conditions under which the error occurred or which
actions and input led to the error.
System environment
SAP-Release 700
Application server... "sap1770"
Network address...... "217.67.56.37"
Operating system..... "Windows NT"
Release.............. "5.2"
Hardware type........ "4x Intel 801586"
Character length.... 16 Bits
Pointer length....... 32 Bits
Work process number.. 0
Shortdump setting.... "full"
Database server... "SAP1770"
Database type..... "MSSQL"
Database name..... "CRO"
Database user ID.. "cro"
Char.set.... "C"
SAP kernel....... 700
created (date)... "Jan 15 2006 23:05:36"
create on........ "NT 5.0 2195 Service Pack 4 x86 MS VC++ 13.10"
Database version. "SQL_Server_8.00 "
Patch level. 41
Patch text.. " "
Database............. "MSSQL 7.00.699 or higher, MSSQL 8.00.194"
SAP database version. 700
Operating system..... "Windows NT 5.0, Windows NT 5.1, Windows NT 5.2"
Memory consumption
Roll.... 8176
EM...... 4180896
Heap.... 0
Page.... 24576
MM Used. 3736976
MM Free. 442176
User and Transaction
Client.............. 100
User................ "DIAGBASIS"
Language Key........ "E"
Transaction......... " "
Program............. "CL_SAM_BSP_SESSION_LAUNCHER===CP"
Screen.............. "SAPMHTTP 0010"
Screen Line......... 2
Information on Caller ofr "HTTP" Connection:
Plug-in Type.......... "HTTP"
Caller IP............. "172.27.104.12"
Caller Port........... 8001
Universal Resource Id. "/sap/bc/bsp/sap/ic_base/main.htm"
Information on where terminated
Termination occurred in the ABAP program "CL_SAM_BSP_SESSION_LAUNCHER===CP" -
in "CREATE_SESSION".
The main program was "SAPMHTTP ".
In the source code you have the termination point in line 23
of the (Include) program "CL_SAM_BSP_SESSION_LAUNCHER===CM002".
Source Code Extract
Line
SourceCde
1
method CREATE_SESSION .
2
3
data: rfcdest type rfcdest.
4
data: status type i.
5
data: http_client type ref to if_http_client.
6
7
rfcdest = destination.
8
cl_http_client=>create_by_destination( EXPORTING destination = rfcdest IMPORTING client =
9
10
http_client->request->set_header_field( name = '~request_uri' value = uri
11
http_client->request->set_header_field( name = '~request_method' value = 'GET'
12
http_client->request->set_header_field( name = if_http_header_fields=>user_agent value = s
13
http_client->send( exporting timeout = 10 ).
14
http_client->receive( ).
15
data = http_client->response->get_data( ).
16
http_client->response->get_status( importing code = status ).
17
http_client->close( ).
18
19
data: s type string. "#EC NEEDED
20
s = cl_sam_toolkit=>x2s( data ).
21
22
if ( status <> 200 ).
>>>>>
raise communication_error.
24
endif.
25
26
27
endmethod.
Not sure how to solve this since couldn't find any relevant notes.
Thanks

Hi KZ,
i've run the CRMS_IC_CHECK and i got following message:
Check System Settings and Status
TIME: 09:33:53
 Configuration summary
 Domain: sapdemo.local
 Context Area Style Sheet:
 Scratch Pad Style Sheet:
 Broadcast Style Sheet:
 General
 Server domains are compatible.
 Logical system: CROCLNT100
The J2EE and HTTP service is running. the CRM_IC is activated. I even got same error when i test the CRM_IC from sicf. Not sure how i can progress further.
Thanks

Raise Exception when execute UCMON

Dear all,
I need help. When we execute the transaction UCMON we have a Dump.
Erro tpo.exec.         RAISE_EXCEPTION
Data e hora            31.01.2011 17:44:30
Dump breve ABAP não está complet.gravado (demas.extenso)
TxtBreve
     Exception condition "NOT_FOUND" raised.
O que aconteceu ?
     The current ABAP/4 program encountered an unexpected
     situation.
O que pode ser feito?
     Print out the error message (using the "Print" function)
     and make a note of the actions and input that caused the
     error.
     To resolve the problem, contact your SAP system administrator.
     You can use transaction ST22 (ABAP Dump Analysis) to view and administer
      termination messages, especially those beyond their normal deletion
     date.
     is especially useful if you want to keep a particular message.
Análise do erro
     A RAISE statement in the program "CL_UC_METHOD==================CP" raised the
      exception
     condition "NOT_FOUND".
     Since the exception was not intercepted by a superior program
     in the hierarchy, processing was terminated.
     Short description of exception condition:
For detailed documentation of the exception condition, use
Transaction SE37 (Function Library). You can take the called
function module from the display of active calls.
as p/eliminação de erros
You may able to find an interim solution to the problem
in the SAP note system. If you have access to the note system you
use the following search criteria:
"RAISE_EXCEPTION" C
"CL_UC_METHOD==================CP" or "CL_UC_METHOD==============
"CREATE_ACCOUNT"
or
"CL_UC_METHOD==================CP" "NOT_FOUND"
or
"UCUWB000 " "NOT_FOUND"
If you cannot solve the problem yourself and you wish to send
an error message to SAP, include the following documents:
1. A printout of the problem description (short dump)
    To obtain this, select in the current display "System->List->
    Save->Local File (unconverted)".
2. A suitable printout of the system log
    To obtain this, call the system log through transaction SM21.
    Limit the time interval to 10 minutes before and 5 minutes
      after the short dump. In the display, then select the function
      "System->List->Save->Local File (unconverted)".
   3. If the programs are your own programs or modified SAP programs,
      supply the source code.
      To do this, select the Editor function "Further Utilities->
      Upload/Download->Download".
   4. Details regarding the conditions under which the error occurred
      or which actions and input led to the error.
Ambiente de sistema
   SAP Release.............. "640"
   Application server....... "cpsapbwp01"
   Network address.......... "172.16.21.222"
   Operating system......... "Linux"
   Release.................. "2.6.18-238.1.1.el5"
   Hardware type............ "x86_64"
   Character length......... 16 Bits
   Pointer length........... 64 Bits
   Work process number...... 2
   Short dump setting....... "full"
   Database server.......... "bwdb"
   Database type............ "ORACLE"
   Database name............ "BWP"
   Database owner........... "SAPCSB"
   Character set............ "C"
   SAP kernel............... "640"
   Created on............... "May 2 2010 20:07:20"
Created in............... "Linux GNU SLES-10 x86_64 cc4.1.2"
Database version......... "OCI_102 "
Patch level.............. "327"
Patch text............... " "
Supported environment....
Database................. "ORACLE 9.2.0.., ORACLE 10.1.0.., ORACLE
10.2.0.."
SAP database version..... "640"
Operating system......... "Linux 2.6"
Memory usage.............
Roll..................... 16192
EM....................... 29328992
Heap..................... 0
Page..................... 65536
MM Used.................. 23444056
MM Free.................. 1691488
SAP Release.............. "640"
Usuário e transação
    Client.............. 600
    User................ "CS096152"
    Language key........ "P"
    Transaction......... "UCWB_INT "
    Program............. "CL_UC_METHOD==================CP"
    Screen.............. "SAPLUCUM_00 1000"
    Screen line......... 3
Infos p/ponto de cancelamento
    The termination occurred in the ABAP program "CL_UC_METHOD==================CP"
     in "CREATE_ACCOUNT".
    The main program was "UCUWB000 ".
    The termination occurred in line 27 of the source code of the (Include)
     program "CL_UC_METHOD==================CM009"
    of the source code of program "CL_UC_METHOD==================CM009" (when
     calling the editor 270).
Segmento texto fonte
Linha Txt.fonte
    1 * bal080305 090305 826099 pass exception not_found to caller
    2 method CREATE_ACCOUNT .
    3
    4   data:
    5     lo_instance type ref to if_uc_cust_data,
    6     lo_account type ref to cl_uc_account.
    7
    8   clear: eo_account, e_accid.                                 "bal080305
    9
   10   if do_account_factory is initial.
   11     do_account_factory = do_factory->get_account_factory( ).
   12   endif.
   13
   14   if i_accid is initial.
   15     call method do_account_factory->create
   16       exporting io_model    = do_model
   17       importing eo_instance = lo_instance.
   18     call method lo_instance->get_guid
   19       importing e_guid = e_accid.
   20   else.
   21     call method do_account_factory->get_instance_by_guid
   22       exporting io_model    = do_model
   23                 i_guid      = i_accid
   24       importing eo_instance = lo_instance
   25       exceptions not_found = 1.                        "begin bal080305
   26     if not sy-subrc is initial.
>>>>>       raise not_found.
   28     endif.                                                "end bal080305
   29     e_accid = i_accid.
   30   endif.
   31   call method lo_instance->set_ffix( dt_ffix ).
   32
   33   if if_stm_timestamp = gc_true.
   34     lo_account ?= lo_instance.
   35     call method lo_account->set_task_stm_timestamp( gc_true ).
   36   endif.
   37
   38   eo_account ?= lo_instance.
   39
   40 endmethod.   31   call method lo_instance->set_ffix( dt_ffix ).
What happens?
Thanks a lot
Marilia Costa

Hi,
I could recollect same kind of issue in our system. In production system we were facing a short dump. however not in Development and quality.
Is it the same issue with you?
If yes. please check the single selections consistency in development & production.
thanks
Kamal

ECL Viewer 5 raise exceptions viewing tif drawings

Hello all,
Bit of a strange one here that hopefully someone may be able to help me with...
We are (still) running 4.6C, on Ora 9.2.0.7 over Windows.
We are running 640 Gui patched to 24
We have deployed (in a failed attempt to stop the error I will describe below) ECL viewer 5.1.3.
Client machines are running XP with SP2
Error:
after entering MM03 and choosing Additional Data > Document Data we click on an attchment (doc type DRG) and choose to view via the display (glasses) icon. The tif file (which is copied into C:\temp) opens. many of the tif files (scanned drawings) have multiple pages so we move to the next page by clicking 'Navigation' > 'next'.
The problem is that after a seemingly random amount of clicks on to next pages a raise exception occurs. After the short dump it is no longer possible to view the document again as we get the error 'file c:\temp\xxxxx.tif cannot be created' and so the only way to view the drawing is either to access the file from the temp directory or completly log out of SAP and relog back in.
i have searched for notes and we were advised to deploy the 5.1.3 viewer which only seems to have made it worse because before the 5.1.3 deployment we were getting many short dumps but the user oddly didn't see the short dump on their screens - now 5.1.3 is in place the user now sees the short dump and calls the support desk very often.
Has anyone been unfortunate enough to have experienced this before or anyone got any brain waves????
yours thankful in advance and loosing the will to live,
Andy
ps here is the short dump extract:
                                                                                Error analysis
A RAISE statement in the program "CL_GUI_CFW====================CP " raised the
exception
condition "CNTL_ERROR".
Since the exception was not intercepted by a superior program
in the hierarchy, processing was terminated.
Short description of exception condition:
For detailed documentation of the exception condition, use
Transaction SE37 (Function Library). You can take the called
function module from the display of active calls.
How to correct the error
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:
"RAISE_EXCEPTION"
"CL_GUI_CFW====================CP " or "CL_GUI_CFW====================CM00P "
"UPDATE_VIEW"
or
"CL_GUI_CFW====================CP " "CNTL_ERROR"
or
"SAPMMG01 " "CNTL_ERROR"
If you cannot solve the problem yourself, please send the
following documents to SAP:
1. A hard copy print describing the problem.
   To obtain this, select the "Print" function on the current screen.
2. A suitable hardcopy prinout of the system log.
   To obtain this, call the system log with Transaction SM21
   and select the "Print" function to print out the relevant
   part.
3. If the programs are your own programs or modified SAP programs,
   supply the source code.
   To do this, you can either use the "PRINT" command in the editor or
   print the programs using the report RSINCL00.

Hi Andy,
I would recommend you to upgrade to the latest available ECL Viewer version 6.
Please see SAP note 1083901.
Further please upgrade also your SAPGUI to the latest patch level as explained in note 164203. After this upgrade please un-install your ECL Viewer 5.1.3 by using one of the following mehtods:
Search for WebViewer2d.dll file. If it is present at more than one place then it means ECL Viewer is installed more than once without uninstalling the previous version (You can check the folders and should be able to see all the dll's for ECL Viewer such WebViewer3d.dll/Printing.dll etc to make sure that there is not only single file but the whole installation).
In this case:
A) Uninstall the version integrated with SAP GUI by using SAP Installation scripts. You need to uncheck the 'EAI Viewer' component in 'General Add-on' option.
B) Check add/remove program and if there is an entry like SAP Viewer, uninstall it.
After this search again, and you should not get WebViewer2d.dll file on machine. Now reinstall the latest Viewer. This should solve most of the issue related to inconsistencies.
Then install the latest ECL Viewer 6 and the issue should be solved.
Best regards,
Christoph

ARV_BC_XMB_DEL Fails With Raise Exception

Hi All,
 I have scheduled the archiving job in PI 7.0 through sxmb_adm -> Schedule Archiving.
 After scheduling I can see two jobs successfully released
 1. ARV_BC_XMB_DEL - This job uses the program "RSXMB_DELETE_ARCHIVED_MESSAGES"
 2. ARV_BC_XMB_WRP - This uses the program "RSXMB_ARCHIVE_MESSAGES"
 The second job (which is archiving of xml messages) is running good but the First Job "ARV_BC_XMB_DEL" fails with a
 "ABAP/4 processor: RAISE_EXCEPTION."
 Both the jobs are running fine on DEV & QA systems.
 But the first job fails on Pre-Prod & Prd (which are high available systems).
 Any hints/help on why its failing with an exception on Pre-PRD & PRD ?
<removed by moderator>
Thanks
Sourav
Edited by: Mike Pokraka on Jul 24, 2008 12:52 PM

Yes. This is what it says.
Short text
 Exception condition "NO_DDIC_TYPE" raised.
What happened?
 The current ABAP/4 program encountered an unexpected
 situation.
What can you do?
 Note down which actions and inputs caused the error.
 To process the problem further, contact you SAP system
 administrator.
 Using Transaction ST22 for ABAP Dump Analysis, you can look
 at and manage termination messages, and you can also
 keep them for a long time.
Error analysis
 A RAISE statement in the program "CL_ABAP_TYPEDESCR=============CP" raised the
 exception
 condition "NO_DDIC_TYPE".
 Since the exception was not intercepted by a superior
 program, processing was terminated.
 Short description of exception condition:
 For detailed documentation of the exception condition, use
 Transaction SE37 (Function Library). You can take the called
 function module from the display of active calls.
How to correct the error
 If the error occures in a non-modified SAP program, you may be able to
 find an interim solution in an SAP Note.
 If you have access to SAP Notes, carry out a search with the following
 keywords:
 "RAISE_EXCEPTION" " "
 "CL_ABAP_TYPEDESCR=============CP" or "CL_ABAP_TYPEDESCR=============CM00C"
 "GET_DDIC_HEADER"
 or
 "CL_ABAP_TYPEDESCR=============CP" "NO_DDIC_TYPE"
 or
 "RSXMB_DELETE_ARCHIVED_MESSAGES " "NO_DDIC_TYPE"
 If you cannot solve the problem yourself and want to send an error
 notification to SAP, include the following information:
 1. The description of the current problem (short dump)
 To save the description, choose "System->List->Save->Local File
 (Unconverted)".
 2. Corresponding system log
 Display the system log by calling transaction SM21.
 Restrict the time interval to 10 minutes before and five minutes
 after the short dump. Then choose "System->List->Save->Local File
 (Unconverted)".
 3. If the problem occurs in a problem of your own or a modified SAP
 program: The source code of the program
 In the editor, choose "Utilities->More
 Utilities->Upload/Download->Download".
 4. Details about the conditions under which the error occurred or which
 actions and input led to the error.

Raise exception in function module call from SAP owned program

I need to raise an exception in a function module to terminate a transaction, display a error message and return to to previous selection screen so the user can fix the error before moving forward.......
How do you do this when the program using the function module is SAP owned?
Thank You!
Jeff

Hi,
After calling the function module, you can do something like this.
IF SY-SUBRC <> 0.
RAISE EXCEPTION.
ENDIF.
Regards,
Ferry Lianto

ST03N Raise Exception Shortdump when Access BI Workload

Dear Experts,
Now i'm using BI 7.0 for SEM-BPS purposes. SAP Support package i used now is
SAPKB70013, SAPKA70013, SAPKIPYJ7D, SAPKW70015, SAPK-60010INFINBASIS, SAPKGS6010 and SAPKIBIIP6.
I have problem when try to check BI Workload via Transaction ST03N, "RAISE_EXCEPTION" shortdump always occured when i double click one of workload date. From ST22, mentioned that the errors is related with "SAPLRSDRI" or "LRSDRIU01" or "RSDRI_INFOPROV_READ".
FYI this short dump didn't occured before i upgraded my system from Suport package 12 to support package 13. I have tried to implement notes number 1088281 (RAISE_EXCEPTION in RSDRI_INFOPROV_READ) and 1002054 (Dump when reading master data providers) but the shordump still occured. Is there any other solution for this? Any help will be highly apreciate.
Below is the summary of the shortdump.
==========================================================
Runtime Errors         RAISE_EXCEPTION
Date and Time          11.12.2007 10:55:04
Short text
     Exception condition "X_MESSAGE" raised.
What happened?
     The current ABAP/4 program encountered an unexpected
     situation.
Error analysis
    A RAISE statement in the program "SAPLRSDRI" raised the exception
    condition "X_MESSAGE".
    Since the exception was not intercepted by a superior
    program, processing was terminated.
    Short description of exception condition:
    Other Error from Deeper Modules
    For detailed documentation of the exception condition, use
    Transaction SE37 (Function Library). You can take the called
    function module from the display of active calls.
How to correct the error
    If the error occures in a non-modified SAP program, you may be able to
    find an interim solution in an SAP Note.
    If you have access to SAP Notes, carry out a search with the following
    keywords:
    "RAISE_EXCEPTION" " "
    "SAPLRSDRI" or "LRSDRIU01"
    "RSDRI_INFOPROV_READ"
    or
    "SAPLRSDRI" "X_MESSAGE"
    or
    "SAPWL_ST03N " "X_MESSAGE"
Information on where terminated
    Termination occurred in the ABAP program "SAPLRSDRI" - in
     "RSDRI_INFOPROV_READ".
    The main program was "SAPWL_ST03N ".
    In the source code you have the termination point in line 160
    of the (Include) program "LRSDRIU01".
============================================================
Thanks,
Bagus

Solution for as was:
Check RSA1 Data Warehouse Workbench -> Modeling -> InfoProvider;
- Search for InfoCube 0TCT_VC01; in the context, check "Activate
Direct Access"; Then, click on the "Source Syst.for InfoSource 3.x"
tab, you have to activate the direct access by marking the source
system (system name) and save.
In ST03N get Short dump exception conditon"x_message"raised
Cheers,
Pavel

Raise Exception Runtime error

Error analysis
A RAISE statement in the program "SAPLTHFB" raised the exception
condition "ALREADY_RUNNING".
Since the exception was not intercepted by a superior program
in the hierarchy, processing was terminated.
Short description of exception condition:
For detailed documentation of the exception condition, use
Transaction SE37 (Function Library). You can take the called
function module from the display of active calls.
How to correct the error
You may able to find an interim solution to the problem
in the SAP note system. If you have access to the note system yourself,
use the following search criteria:
"RAISE_EXCEPTION" C
"SAPLTHFB" or "LTHFBU09"
"TH_INIT_COLLECTOR_ARRAY"
or
"SAPLTHFB" "ALREADY_RUNNING"
or
"RSM13000 " "ALREADY_RUNNING"
Source code extract
000430 end_of_data = 1.
000440 end_of_vbcontext = 1.
000450 describe field func length func_len in character mode.
000460
000470
000480 * J.B. (6.3.00): collective runs must not run concurrent for
000490 * one function module
000500 *
000510 * el (23.11.01): add server group to enqueue argument to allow
000520 * parallel collective runs in different server groups
000530 describe field enq_vbcontext length context_len in character mode.
000540 gran_list-gname = 'UPDCOLLRUN'.
000550 gran_list-gmode = 'E'.
000560 gran_list-garg = client.
000570 offset = 3.
000580 gran_list-garg+3(func_len) = func.
000590 add func_len to offset.
000600 gran_list-garg+offset(context_len) = enq_vbcontext.
000610 append gran_list.
000620
000630 call 'C_ENQUEUE'
000640 id 'OPCODE' field '1'
000650 id 'ENQOBJ' field 'UPDCOLLRUN'
000660 id 'GRANULES' field gran_list-sys
000670 id 'DELAY_ON_REJECT' field ' '
000680 id 'USTP' field '2'
000690 id 'COLLISION_UNAME' field user
000700 id 'COLLISION_OBJECT' field obj
000710 id 'SYNCHRON' field 'X'.
000720 if sy-subrc <> 0.
> raise already_running. -
/* error occurs at this line-----*\
000740 endif.
000750
000760
000770 if vbcontext = '*'.
000780 call 'ThVBCall' id 'OPCODE' field get_server_names
000790 id 'VBCONTEXT' field vbcontext.
000800 endif.
plz help me to understand this error

Simple, you cannot run collective runs in parallel...
Note 436094 - Short dump ALREADY_RUNNING
If the collective run is running in parallel on different clients read
Note 595671 - Collective run processing in several clients
Regards
Juan

Exception in non-transactional EJB invoke:java.lang.NoSuchMethodError

Hello,
Iam facing with the following exception while deploying EJB's in Weblogic 5.1. The TX Datasource is setup properly and the application is running fine, when I have modified an existing EJB and while re-deploying, getting the following error:
Fri Jun 30 22:30:53 EST 2006: <EJB JAR deployment ./lib/deployablePAM_EJB.jar> Exception in non-transactional EJB invoke:
java.lang.NoSuchMethodError
at com.bp.downstream.retail.au.pam.dsaf.ejb.site.SiteBeanHomeImpl.preFinderInvoke(SiteBeanHomeImpl.java:906)
at com.bp.downstream.retail.au.pam.dsaf.ejb.site.SiteBeanHomeImpl.findByGroupIdAgentFlag(SiteBeanHomeImpl.java:217)
at com.bp.downstream.retail.au.pam.dsaf.ejb.site.SiteBeanHomeImpl_ServiceStub.findByGroupIdAgentFlag(SiteBeanHomeImpl_Servi)
at com.bp.downstream.retail.au.pam.dsaf.dso.site.SiteDSOEjbImpl.getSitesByGroupIDAgentFlagWithMarkers(SiteDSOEjbImpl.java:9)
at com.bp.downstream.retail.au.pam.services.ejb.price.PriceBean.getGroupPrices(PriceBean.java:1366)
at com.bp.downstream.retail.au.pam.services.ejb.price.PriceBeanEOImpl.getGroupPrices(PriceBeanEOImpl.java:366)
at com.bp.downstream.retail.au.pam.services.serviceobject.GetGroupPrices.callService(GetGroupPrices.java:74)
at au.com.oakton.ecore.services.ServiceManager.callService(ServiceManager.java:47)
at au.com.oakton.ecore.request.RequestHandler.processRequest(RequestHandler.java:173)
at com.bp.downstream.retail.au.pam.serviceaccess.ServiceBean.invoke(ServiceBean.java:66)
at com.bp.downstream.retail.au.pam.control.PriceGroupAction.perform(PriceGroupAction.java:94)
at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1786)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1585)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:772)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:158)
at org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.java:1758)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:772)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:158)
at org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.java:1758)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:772)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:158)
at org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.java:1758)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:772)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:158)
at org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.java:1758)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:772)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:915)
at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:879)
at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:269)
at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:365)
at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:253)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129)
Please help me in understanding when we get such an exception.

Hello All,
I am getting the 'Exception in non-transactional EJB invoke:java.lang.NoSuchMethodError', even if I have not made any modifications in the code. As and when I am re-deploying the deployablePAM_EJB.jar, and exception is raised. I am I missing out something here ?.
Please let me know.

Re: Raising Exceptions Vs returning erro[Ref:C809787]

Hi Steve !
Probably the following explanation might help in resolving the issue raised by
you:
At a more abstract level, there is only one thing, i.e. the EVENT. According to
it's definition, an event is a relatively infrequent occurrence in one portion (lets
call it event raiser) of the application, which some other portion (or portions,
lets call them event handlers) (of the same application) are interested to respond
to it. Now there are two scenarios:
(A) Event raiser and Event handler(s) are being executed under different threads
of control (Asynchronous) and
(B) Event raiser and Event Handler(s) are being executed under same thread of
control (Synchronous).
So, Exception Handling belongs to scenario B where the method raising the
exception (Event Raiser or exception raiser) and the method handling it (Event
Handler or exception block) are under the same thread of control. More ever it has
to be insured that at a time only one handler (first the inner most one) receives
the message.
Forté provides a generic Event handling mechanism (Post Event and Event Loop) to
handle the scenario A (which is the more generic one). But it also provides a
specialized Event Handling mechanism (Raise Exception and Exception block) to
efficiently handle the relatively simple scenario B. Why I am saying that the later
is efficient because it won't be needing to register the event queue address of the
interested task (after all there is only one task involved) and put the event
message in queue.
Finally let me mentioned that it is just my view based on the understanding I
have and it may not be true. Only a person from forté can confirm it. I will really
appreciate if somebody correct and or refine it.
Wish a Very Very Happy New Year to all Forté Users
Regard,
Kailash.
[email protected] wrote:
I would agree with Eric entirely. Exceptions seem to me to be a much more
complete solution to the problem of error handling. A little bit of effort up
front in making clear the strategy for exception handling and specifying the
exceptions that can be raised by a class\method will provide an excellent method
for error handling.
In the case of ensuring exceptions are always handled, a top level handler for
GenericException will usually do the job, allowing you to write error
information out to logs, screen, etc, and then shut down gracefully.
The only issue I would raise with exceptions is that they are not propagated
outside an asynchronous task. If an exception is not handled within an
asynchronous, it will not propagate to the task that started that asynchronous
task. Forte provides return and exception events when starting asynchronous
tasks to cope with this, but it seems a shame to have one method of dealing with
errors (exceptions) for synchronous behaviour, and another (events) for
asynchronous behaviour.
Steve Elvin
Systems Developer
Frontline Ltd.
UK
Mark,
The problem with return codes is that there is an underlying assumption
that the receiver will always catch and interpret that error code. This
may or may not be good thing, depending on how you architect your
application. If, on the other hand, you want to ensure that an error is
always handled, if not by the receiver then by the Forte, Exceptions are
the way to go. To extend this mechanism further, I would subclass
GenericException and created my own error code attribute on that
subclass. That way the receiver has the choice of interpreting the
exception based on that error code, and wrapping it in a
MessageDialog/window or do the usual 'errormgr.showerrors()'.
Exceptions seem a more flexible approach to me. That is, if you can live
with the fact that by using it, you're violating the 'exceptions for
behavioral anomalies' software engineering principle !
Best wishes.
Eric Pereira
Forte Consultant
----Original Message Follows----
From: "Kallambella, Ajith" <[email protected]>
To: "'Mark Sundsten'" <[email protected]>, [email protected]
Cc: [email protected]
Subject: RE: Raising Exceptions Vs returning error codes
Date: Wed, 30 Dec 1998 08:52:39 -0500
Reply-To: "Kallambella, Ajith" <[email protected]>
Mark,
Identifying conditions where you would rather use an exception
to an error_code ( and vice-versa ) normally depends on
your application design. Usually exceptions
are used to handle behavioral anomalies which are
not expected during the normal course of execution of
the program, and which would affect the continuity of
your algorithm if ignored. Examples would be a fatal
error, a semantically invalid( but syntactically-valid
token ) etc.
Error_codes and return status's can be used to handle
anticipated and recoverable errors. Example would
be presentation layer validations. In any normal
UI system, the user is expected to make errors and it
would be annoying to throw an exception( and to handle
it ), every time user enters wrong data. A well
modeled client layer should not only handle
data-validation errors , but should be smart enough
to encourage users to input correct or
"near-correct" data. Examples could be
making use of look-up windows etc. Interestingly,
Express uses exceptions to handle data-validations.
As you see, exceptions fit well into your processing
logic where severity of damage caused by an error
is more. Where as error_codes fit well into presentation
logic( and some not-so-critical processing logic ) where
errors are usually recoverable and normal path of
execution can be easily restored.
Hope this helps. I would be very interested to hear
what others have to say.
Ajith Kallambella. M
Forte Systems Engineer,
International Business Corporation.
-----Original Message-----
From: Mark Sundsten [mailto:[email protected]]
Sent: Tuesday, December 29, 1998 2:10 PM
To: [email protected]
Cc: [email protected]
Subject: Raising Exceptions vs returning error codes
When dealing with error handling, I find myself struggling with the
choice
of
raising exceptions (and handling them) from the caller
vs returning an error code of somekind.
When would you want to use one over the other?
Should you always use exception handling?
Any discussion would be appreciated.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Hi Steve !
Probably the following explanation might help in resolving the issue raised by
you:
At a more abstract level, there is only one thing, i.e. the EVENT. According to
it's definition, an event is a relatively infrequent occurrence in one portion (lets
call it event raiser) of the application, which some other portion (or portions,
lets call them event handlers) (of the same application) are interested to respond
to it. Now there are two scenarios:
(A) Event raiser and Event handler(s) are being executed under different threads
of control (Asynchronous) and
(B) Event raiser and Event Handler(s) are being executed under same thread of
control (Synchronous).
So, Exception Handling belongs to scenario B where the method raising the
exception (Event Raiser or exception raiser) and the method handling it (Event
Handler or exception block) are under the same thread of control. More ever it has
to be insured that at a time only one handler (first the inner most one) receives
the message.
Forté provides a generic Event handling mechanism (Post Event and Event Loop) to
handle the scenario A (which is the more generic one). But it also provides a
specialized Event Handling mechanism (Raise Exception and Exception block) to
efficiently handle the relatively simple scenario B. Why I am saying that the later
is efficient because it won't be needing to register the event queue address of the
interested task (after all there is only one task involved) and put the event
message in queue.
Finally let me mentioned that it is just my view based on the understanding I
have and it may not be true. Only a person from forté can confirm it. I will really
appreciate if somebody correct and or refine it.
Wish a Very Very Happy New Year to all Forté Users
Regard,
Kailash.
[email protected] wrote:
I would agree with Eric entirely. Exceptions seem to me to be a much more
complete solution to the problem of error handling. A little bit of effort up
front in making clear the strategy for exception handling and specifying the
exceptions that can be raised by a class\method will provide an excellent method
for error handling.
In the case of ensuring exceptions are always handled, a top level handler for
GenericException will usually do the job, allowing you to write error
information out to logs, screen, etc, and then shut down gracefully.
The only issue I would raise with exceptions is that they are not propagated
outside an asynchronous task. If an exception is not handled within an
asynchronous, it will not propagate to the task that started that asynchronous
task. Forte provides return and exception events when starting asynchronous
tasks to cope with this, but it seems a shame to have one method of dealing with
errors (exceptions) for synchronous behaviour, and another (events) for
asynchronous behaviour.
Steve Elvin
Systems Developer
Frontline Ltd.
UK
Mark,
The problem with return codes is that there is an underlying assumption
that the receiver will always catch and interpret that error code. This
may or may not be good thing, depending on how you architect your
application. If, on the other hand, you want to ensure that an error is
always handled, if not by the receiver then by the Forte, Exceptions are
the way to go. To extend this mechanism further, I would subclass
GenericException and created my own error code attribute on that
subclass. That way the receiver has the choice of interpreting the
exception based on that error code, and wrapping it in a
MessageDialog/window or do the usual 'errormgr.showerrors()'.
Exceptions seem a more flexible approach to me. That is, if you can live
with the fact that by using it, you're violating the 'exceptions for
behavioral anomalies' software engineering principle !
Best wishes.
Eric Pereira
Forte Consultant
----Original Message Follows----
From: "Kallambella, Ajith" <[email protected]>
To: "'Mark Sundsten'" <[email protected]>, [email protected]
Cc: [email protected]
Subject: RE: Raising Exceptions Vs returning error codes
Date: Wed, 30 Dec 1998 08:52:39 -0500
Reply-To: "Kallambella, Ajith" <[email protected]>
Mark,
Identifying conditions where you would rather use an exception
to an error_code ( and vice-versa ) normally depends on
your application design. Usually exceptions
are used to handle behavioral anomalies which are
not expected during the normal course of execution of
the program, and which would affect the continuity of
your algorithm if ignored. Examples would be a fatal
error, a semantically invalid( but syntactically-valid
token ) etc.
Error_codes and return status's can be used to handle
anticipated and recoverable errors. Example would
be presentation layer validations. In any normal
UI system, the user is expected to make errors and it
would be annoying to throw an exception( and to handle
it ), every time user enters wrong data. A well
modeled client layer should not only handle
data-validation errors , but should be smart enough
to encourage users to input correct or
"near-correct" data. Examples could be
making use of look-up windows etc. Interestingly,
Express uses exceptions to handle data-validations.
As you see, exceptions fit well into your processing
logic where severity of damage caused by an error
is more. Where as error_codes fit well into presentation
logic( and some not-so-critical processing logic ) where
errors are usually recoverable and normal path of
execution can be easily restored.
Hope this helps. I would be very interested to hear
what others have to say.
Ajith Kallambella. M
Forte Systems Engineer,
International Business Corporation.
-----Original Message-----
From: Mark Sundsten [mailto:[email protected]]
Sent: Tuesday, December 29, 1998 2:10 PM
To: [email protected]
Cc: [email protected]
Subject: Raising Exceptions vs returning error codes
When dealing with error handling, I find myself struggling with the
choice
of
raising exceptions (and handling them) from the caller
vs returning an error code of somekind.
When would you want to use one over the other?
Should you always use exception handling?
Any discussion would be appreciated.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Error text missing in raising exception (In ABAP mapping)

Hi,
iam using ABAP Mapping for 1 interface.
Based on some condition i am raising exception with error text. When i executed this in SXI_Mapping_test it's showing the Error text. But when i execute the interface directly error text is missing in the Error details.
can any one figure out y its not coming..
regards
Kishore

Hi,
I think you need to write the error to mapping trace.
http://help.sap.com/saphelp_nw04/helpdata/en/ba/e18b1a0fc14f1faf884ae50cece51b/content.htm
Regards
Vijaya

Error in Raising exceptions in a method and handling the same in the WF

Hi All
I tried to implement Raising exceptions in a method and handling the same in the workflow
in the same way given in SAPtechnical site .
1.by adding a error msg in exception parameter .
2. if the select query fails, to fetch the agent then :exit_return 9001 'ztable name' space space space.
3.in the Background activity in which this method is called there automatically one outcome appears ,and I hav acitvated that outcome and in that done what need to be done for that error handling - just send a mail to concern person .
4. in the normal outcome of the activity , the step to be executed are there .
but its not working , if exception come then the WF stuck there only . it do not follow the exception outcome .
Kindly help me , How can I do the exception handly in WF.
thanks & Regards
Kakoli

> That is usually the case - you catch an error in the underlying program and pass that back so the workflow can go into error.
> You're doing it correctly.
I don't think that's quite right.
If you define an error/exception in a method, it is automatically mapped to an outcome of the step/task.
If you activate that outcome, then you can handle the exception in a branch of the workflow.
For example: 'Remote connection is down, please contact Basis'
The step should only go into error if an outcome occurs that you have NOT activated.
So the original question is valid. Please give some more information on what the error message is..
chrs
Paul

Raising exceptions in PL/SQL

Hi Friends
I have the following code:
declare
var1....
var2....
cursor c1
begin
insert stmt;
update stmt;
update stmt;
for r1 in c1 loop
end loop;
end;
I will be having about 6-7 million rows every month to process. To raise exceptions, I am thinking of either of the following options:
Option 1_
declare
var1....
var2....
var3 exception;
var4 exception;
var5 exception;
cursor c1
begin
insert stmt;
update stmt;
IF SQL%NOTFOUND then
var3;
end if;
update stmt;
IF SQL%NOTFOUND then
var4;
end if;
for r1 in c1 loop
end loop;
IF SQL%NOTFOUND then
var5;
end if;
Exception
when var3 then blah blah
when var4 then blah blah
when var5 then blah blah
end;
Option 2_
declare
var1....
var2....
cursor c1
begin
insert stmt;
update stmt;
update stmt;
for r1 in c1 loop
end loop;
Exception
when others then blah blah
end;
In terms of performance, which option is better? And is there any better option?
Thanks....

In terms of performance, which option is better? And is there any better option?If you consider in terms of performance i think you cant find any difference in both ways.
But your both code does not do the same thing. They are entirely different. They are not the same.
For example, If your UPDATE statement fails with a Too many rows error what will happen.
In the first procedure the procedure will raise the error to the client. But in the second case the error is caught by the WHEN OTHERS block.
So now here the real thing is what you do in the WHEN OTHERS block. Do you suppress the error? Do you return NULL? What do you do, That is what matters.
Your Bla..Bla..Bla.. part in the EXCEPTION is very important. Most of them do mistake there.
WHEN OTHERS is a great feature. But it must be used properly. Its like a very sharp knife. If you dont use it properly there will be blood.

Raising Exceptions in WDA?

Hi,
   I want to know about raising exception in wda. Please explain in details.
Scenario: I have one input field as mandatory. if i click the button without filling that input field, self defined exception should raise. How to do this?
Thanks,
Gopi.

hi ,
place a UI message area in the RootElement Containeru cn make use of control wizard ( CONTROL + F7) to generate error or exception messages
select the radio button , generate messages and choose the method report_error_message
this code wud be automatically generated thru code wizard
* get message manager
DATA lo_api_controller     TYPE REF TO if_wd_controller.
DATA lo_message_manager    TYPE REF TO if_wd_message_manager.
lo_api_controller ?= wd_this->wd_get_api( ).
CALL METHOD lo_api_controller->get_message_manager
RECEIVING
    message_manager = lo_message_manager
* report message
CALL METHOD lo_message_manager->report_error_message
EXPORTING
    message_text              =   'Error_Text' " Give your error text here.
regards,
amit

Raising exceptions in event handlers?

Hi
Is it possible to raise exceptions in event handler? As an example, I added a listener to a UnitOfWork, and implemented the preCommitUnitOfWork() method. In the method, I'm performing some operations, and if something goes wrong, I need to roll back the entire UnitOfWork. Is this possible to raison an exception, or is there some other way to acheive this?
Thanks
Regards
Eric

Hi
Is it possible to raise exceptions in event handler? As an example, I added a listener to a UnitOfWork, and implemented the preCommitUnitOfWork() method. In the method, I'm performing some operations, and if something goes wrong, I need to roll back the entire UnitOfWork. Is this possible to raison an exception, or is there some other way to acheive this?Eric,
I tried this and had some success with a simple test case. I created an exception that extends the oracle.toplink.exceptions.TopLinkException class. Then I added the throws clause to the preCommitUnitOfWork event handler. Throwing my custom exception (that extends TopLinkException) from the event handler works fine and should allow you to retry your update, etc. Note that as long as the exception is thrown at "preCommit" time you should not need to roll anything back as the updates were not applied to the cache or DB. Also, if you applied updates to your registered clones instead of the original objects, the original objects state should be unchanged.
Hope this helps,
Pete Farkas

Raise Exception in IW31 Transaction

Similar Messages

Maybe you are looking for