This discussion is archived
3 Replies Latest reply: Sep 23, 2013 1:17 PM by K Cannell RSS

Error processing request  ORACLE-01403:no data found

K Cannell Newbie
Currently Being Moderated

We surmounted the blank page issue by applying the patch to APEX 4.2.2.

Now we patched/upgraded to APEX 4.2.3, and no longer have the blank page issue, but have this one that seems similar:

 

I am trying here, since I am not getting any debug messages - the POST goes in and immediately comes back with the no data found error.

 

APEX 4.2.3

APEX Listener 2.0.2

Glassfish 4.0

 

Apps install OK, and can display the Login page (Show), but when trying to Login (Accept),

immediately get this error:

Error Error processing request

          ORA-010403: no data found

 

Debug messages only shows Show entries - nothing , not even the Accept first line.

Firebug shows similar - upon Post (which looks OK) the immediate response is the error page and message.

 

I do not have access to the APEX Listener logs tonight,  but expect to get to them, or have someone check them

out, tomorrow AM.

 

Any thoughts or suggestions?

This happens across all apps (15) except for one.  Am still trying to discern the different in that app vs the others.

 

Thank you -

  • 1. Re: Error processing request  ORACLE-01403:no data found
    K Cannell Newbie
    Currently Being Moderated

    An update:

    I have verified that some apps work, and some apps show the

    Error Error processing request

            ORA-01403: no data found

    error.

    Happens across different workspaces.

     

    Have confirmed that for an app that has the error,

       I get the error using the APEX Listener deployment. 

       I do NOT get the error using the HTTP server deployment.

    This is the same in a Linux environment and in a Windows environment.

     

    For one app, I have an earlier version that gives the error, a later version (new app #) that does not give the error.

    APEX 4.2.3

    APEX Listener 2.0.3.221.10/3

    Glassfish 4.0

     

    Again even at  Debug Level 9, I get no debug entries for the POST

    For an app that gives the error, the APEX Listener log entries are (from the POST):

    ==== Processing Request: ====
    Attempting to process with PL/SQL Gateway
    user-agent: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0
    host: qdcls1534:8082
    Applied database connection info
    POST /apex/apexd2/wwv_flow.accept
    ==== Headers in Request ====
    ==== Cookies in Request ====
    content-length: 412
    content-type: application/x-www-form-urlencoded;charset=UTF-8
    request parameter: p_flow_id=440
    request parameter: p_flow_id=440
    request parameter: p_flow_step_id=101
    request parameter: p_instance=1712832201985
    request parameter: p_instance=1712832201985
    request parameter: p_page_submission_id=8493461183923
    request parameter: p_page_submission_id=35145982114211
    request parameter: p_request=LOGIN
    request parameter: p_request=
    request parameter: p_debug=LEVEL9
    request parameter: p_debug=LEVEL9
    request parameter: p_arg_names=13616030313099104709
    request parameter: p_arg_names=13616030522289104711
    request parameter: p_t01=karen.x.cannell
    request parameter: p_t02=sssssssss
    request parameter: p_md5_checksum=
    request parameter: p_page_checksum=C2302553B43577579FF77585749CA016
    Using Procedure:wwv_flow.accept
    request parameter: p_flow_step_id=101
    Requesting Pool:apexd2
    pool exists: apexd2
    isValidRequest(), procedure name: <wwv_flow.accept>
    Validating: wwv_flow.accept
    *** Total number of arguments: 510
    SID: 214
    *** Total number of arguments: 510
    "-----
    begin
    wwv_flow.accept(p_flow_step_id=>?,
    p_md5_checksum=>?,
    p_arg_names=>?,
    p_page_checksum=>?,
    p_t02=>?,
    p_t01=>?,
    p_debug=>?,
    p_request=>?,
    p_page_submission_id=>?,
    p_flow_id=>?,
    p_instance=>?);
    commit;
      end;"
    Parse: 0 ms
    p_flow_step_id= null
    p_flow_step_id=[101, 101]
    {p_md5_checksum=, p_page_submission_id=[8493461183923, 35145982114211], p_debug=[LEVEL9, LEVEL9], p_page_checksum=C2302553B43577579FF77585749CA016, p_request=[LOGIN, ], p_t02=sssssssss, p_t01=karen.x.cannell, p_flow_id=[440, 440], p_instance=[1712832201985, 1712832201985], p_flow_step_id=[101, 101], p_arg_names=[13616030313099104709, 13616030522289104711]}
    p_request=[LOGIN, ]
    p_md5_checksum=
    {p_md5_checksum=, p_page_submission_id=[8493461183923, 35145982114211], p_debug=[LEVEL9, LEVEL9], p_page_checksum=C2302553B43577579FF77585749CA016, p_request=[LOGIN, ], p_t02=sssssssss, p_t01=karen.x.cannell, p_flow_id=[440, 440], p_instance=[1712832201985, 1712832201985], p_flow_step_id=[101, 101], p_arg_names=[13616030313099104709, 13616030522289104711]}
    p_arg_names=[13616030313099104709, 13616030522289104711]
    p_arg_names: {13616030313099104709, 13616030522289104711}
    {p_md5_checksum=, p_page_submission_id=[8493461183923, 35145982114211], p_debug=[LEVEL9, LEVEL9], p_page_checksum=C2302553B43577579FF77585749CA016, p_request=[LOGIN, ], p_t02=sssssssss, p_t01=karen.x.cannell, p_flow_id=[440, 440], p_instance=[1712832201985, 1712832201985], p_flow_step_id=[101, 101], p_arg_names=[13616030313099104709, 13616030522289104711]}
    {p_md5_checksum=, p_page_submission_id=[8493461183923, 35145982114211], p_debug=[LEVEL9, LEVEL9], p_page_checksum=C2302553B43577579FF77585749CA016, p_request=[LOGIN, ], p_t02=sssssssss, p_t01=karen.x.cannell, p_flow_id=[440, 440], p_instance=[1712832201985, 1712832201985], p_flow_step_id=[101, 101], p_arg_names=[13616030313099104709, 13616030522289104711]}
    p_instance= null
    p_instance=[1712832201985, 1712832201985]
    {p_md5_checksum=, p_page_submission_id=[8493461183923, 35145982114211], p_debug=[LEVEL9, LEVEL9], p_page_checksum=C2302553B43577579FF77585749CA016, p_request=[LOGIN, ], p_t02=sssssssss, p_t01=karen.x.cannell, p_flow_id=[440, 440], p_instance=[1712832201985, 1712832201985], p_flow_step_id=[101, 101], p_arg_names=[13616030313099104709, 13616030522289104711]}
    p_flow_id= null
    p_flow_id=[440, 440]
    {p_md5_checksum=, p_page_submission_id=[8493461183923, 35145982114211], p_debug=[LEVEL9, LEVEL9], p_page_checksum=C2302553B43577579FF77585749CA016, p_request=[LOGIN, ], p_t02=sssssssss, p_t01=karen.x.cannell, p_flow_id=[440, 440], p_instance=[1712832201985, 1712832201985], p_flow_step_id=[101, 101], p_arg_names=[13616030313099104709, 13616030522289104711]}
    p_page_submission_id= null
    p_page_submission_id=[8493461183923, 35145982114211]
    {p_md5_checksum=, p_page_submission_id=[8493461183923, 35145982114211], p_debug=[LEVEL9, LEVEL9], p_page_checksum=C2302553B43577579FF77585749CA016, p_request=[LOGIN, ], p_t02=sssssssss, p_t01=karen.x.cannell, p_flow_id=[440, 440], p_instance=[1712832201985, 1712832201985], p_flow_step_id=[101, 101], p_arg_names=[13616030313099104709, 13616030522289104711]}
    p_request= null
    p_md5_checksum=
    {p_md5_checksum=, p_page_submission_id=[8493461183923, 35145982114211], p_debug=[LEVEL9, LEVEL9], p_page_checksum=C2302553B43577579FF77585749CA016, p_request=[LOGIN, ], p_t02=sssssssss, p_t01=karen.x.cannell, p_flow_id=[440, 440], p_instance=[1712832201985, 1712832201985], p_flow_step_id=[101, 101], p_arg_names=[13616030313099104709, 13616030522289104711]}
    p_debug= null
    p_debug=[LEVEL9, LEVEL9]
    {p_md5_checksum=, p_page_submission_id=[8493461183923, 35145982114211], p_debug=[LEVEL9, LEVEL9], p_page_checksum=C2302553B43577579FF77585749CA016, p_request=[LOGIN, ], p_t02=sssssssss, p_t01=karen.x.cannell, p_flow_id=[440, 440], p_instance=[1712832201985, 1712832201985], p_flow_step_id=[101, 101], p_arg_names=[13616030313099104709, 13616030522289104711]}
    p_t01= karen.x.cannell
    p_t01=karen.x.cannell
    {p_md5_checksum=, p_page_submission_id=[8493461183923, 35145982114211], p_debug=[LEVEL9, LEVEL9], p_page_checksum=C2302553B43577579FF77585749CA016, p_request=[LOGIN, ], p_t02=sssssssss, p_t01=karen.x.cannell, p_flow_id=[440, 440], p_instance=[1712832201985, 1712832201985], p_flow_step_id=[101, 101], p_arg_names=[13616030313099104709, 13616030522289104711]}
    p_t02= sssssssss
    p_t02=sssssssss
    {p_md5_checksum=, p_page_submission_id=[8493461183923, 35145982114211], p_debug=[LEVEL9, LEVEL9], p_page_checksum=C2302553B43577579FF77585749CA016, p_request=[LOGIN, ], p_t02=sssssssss, p_t01=karen.x.cannell, p_flow_id=[440, 440], p_instance=[1712832201985, 1712832201985], p_flow_step_id=[101, 101], p_arg_names=[13616030313099104709, 13616030522289104711]}
    p_page_checksum= C2302553B43577579FF77585749CA016
    p_page_checksum=C2302553B43577579FF77585749CA016
    Exec: 37 ms
    ==== Headers from Results ====
    Setting Content-Type (Content-type): text/html; charset=UTF-8
    Got results length: 307
    Processed PL/SQL Gateway request
    ==== Request Processed ====


     

    It just stops ...

    Any ideas?

     

    I have tried all of the Compatibility settings, no difference.

     

    If it is something I can change in the app, that would be great.

    The app that does not work was imported from an APEX 4.1 instance.

    The app that does work was imported from an APEX 4..3 instance (Windows, APEX 4.2.3, APEX Listener 2.0.3, recently upgraded from APEX 4.2.2 and APEX Listener 2.0.2).

     

    Any help or suggestions will be greatly appreciated,

    Karen

  • 2. Re: Error processing request  ORACLE-01403:no data found
    Christian Neumueller Expert
    Currently Being Moderated

    For reference, this is the APEX thread to this problem: https://forums.oracle.com/message/11200124

  • 3. Re: Error processing request  ORACLE-01403:no data found
    K Cannell Newbie
    Currently Being Moderated

    The issue turned out to be a bad page template, where two #FORM_OPEN# directives were causing multiple submission of key page items.   Remove the 2nd #FORM_OPEN# from the page template (and we had them in both the Login Page Template and the standard default page template), and all works fine.

     

    Use of the APEX Listener uncovered the problem that had been there all along.

    Deployment via the HTTP server, this never caused a visible issue.

    This series of apps was  first built in HTMLDB 2.0 and upgraded several times. No telling how long that 2nd #FORM_OPEN# has been in there.   Am just glad it is gone now.

     

    We also had to move some processes on our Login page from Before Header to Before Regions for them to function properly, due to the shift in exactly when APEX 4.1.1+ apps process Before and After Header stuff.  See the item Help on the Compatibility Mode element in the Application Properties for more information.

    Our upgrade was from APEX 4.1.0 to APEX 4.2.3, not a big jump but significant in this aspect.

     

    See also this link for more information to be aware of on Login/Logout process when moving from APEX 4.1 to APEX 4.1.1  and higher:

    Login/Logout Handling in Apex 4.1.1 | Christophs 2 Oracle Cents

     

    Thanks to all for the suggestions that led me to track this down,

    Karen

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points