{"id":763,"date":"2024-08-21T13:25:43","date_gmt":"2024-08-21T11:25:43","guid":{"rendered":"https:\/\/ilmarkerm.eu\/blog\/?p=763"},"modified":"2024-08-21T13:26:27","modified_gmt":"2024-08-21T11:26:27","slug":"application-express-is-currently-unavailable-part-2","status":"publish","type":"post","link":"https:\/\/ilmarkerm.eu\/blog\/2024\/08\/application-express-is-currently-unavailable-part-2\/","title":{"rendered":"Application Express is currently unavailable &#8211; part 2"},"content":{"rendered":"\n<p><a href=\"https:\/\/ilmarkerm.eu\/blog\/2023\/07\/curious-case-of-application-express-is-currently-unavailable-after-downgrade\/\" data-type=\"post\" data-id=\"646\">I previously wrote about how after successfully downgrading APEX users still get the error &#8220;Application Express is currently unavailable&#8221;.<\/a> I now ran to the same issue again, with newer versions and the procedure how ORDS detects is APEX is currently being patched has changed.<\/p>\n\n\n\n<p>This post is about downgrading to APEX 23.1 and ORDS 24.1.<\/p>\n\n\n\n<p>After completing APEX downgrade to 23.1, ORDS 24.1 still reported that &#8220;Application Express is currently unavailable&#8221;. I followed my own previous blog and flipped the APEX internal patching status to APPLIED, but no luck this time. PANIC! I turned on tracking for ORDS sessions and this PL\/SQL block seems to be the culprit.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>DECLARE\n    NM         OWA.VC_ARR := :1 ;\n    VL         OWA.VC_ARR := :2 ;\n    L_PATCH    VARCHAR2(10) := null;\n    L_VERSION  VARCHAR2(100) := null;\n    SCHEMA     VARCHAR2(30);\n    PART1      VARCHAR2(30);\n    PART2      VARCHAR2(30);\n    DBLINK     VARCHAR2(30);\n    PART1_TYPE NUMBER(10);\n    OBJECT_NUM NUMBER(10);\nBEGIN\n    OWA.INIT_CGI_ENV(:3 , NM, VL);\n    HTP.INIT;\n    HTP.HTBUF_LEN := 63;\n \n  --CHECK THE SCHEMA OVERRIDE FOR PL\/SQL GATEWAY APPLICATION DETAILS\n  DECLARE\n    GATEWAY_DETAILS VARCHAR2(2000) := q'&#91; SELECT    \n                                    (SELECT VALUE FROM ORDS_METADATA.USER_ORDS_PROPERTIES WHERE KEY = 'plsql.gateway.patching') as patchingValue, \n                                    (SELECT VALUE FROM ORDS_METADATA.USER_ORDS_PROPERTIES WHERE KEY = 'plsql.gateway.version') as versionValue \n                                    FROM dual]';\n  BEGIN\n    BEGIN\n       EXECUTE IMMEDIATE GATEWAY_DETAILS INTO L_PATCH, L_VERSION;\n    EXCEPTION\n       WHEN OTHERS THEN\n           -- ignore exception and leave l_patch as null so fallback is executed\n           NULL;\n    END;\n \n    IF L_PATCH IS NULL THEN\n    -- L_PATCH  IS NULL, EITHER AN OLDER VERSION OF APEX IS PRESENT OR APEX IS NOT INSTALLED\n    -- CHECK IF APEX PRESENT\n      DECLARE\n        L_SQL VARCHAR2(200) := 'select patch_applied from apex_release';\n      BEGIN\n        DBMS_UTILITY.NAME_RESOLVE('APEX_RELEASE', 0, SCHEMA, PART1, PART2, DBLINK, PART1_TYPE, OBJECT_NUM);\n        EXECUTE IMMEDIATE L_SQL INTO L_PATCH;\n      EXCEPTION\n        WHEN OTHERS THEN\n        -- Could not access apex_release. Default l_patch to 'N' so it's still served \n          L_PATCH :='N';\n      END;\n    END IF;\n  END;\n    :4  := L_PATCH;\n    :5  :=L_VERSION; \nEND;<\/code><\/pre>\n\n\n\n<p>The flag that tells ORDS that APEX is currently being patched has been moved to ORDS_METADATA schema. And in my case the query indeed returned TRUE.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>SELECT VALUE FROM ORDS_METADATA.USER_ORDS_PROPERTIES WHERE KEY = 'plsql.gateway.patching'<\/code><\/pre>\n\n\n\n<p>After flipping it to FALSE, downgraded APEX started working again.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>UPDATE ORDS_METADATA.USER_ORDS_PROPERTIES set value='FALSE' WHERE KEY = 'plsql.gateway.patching';<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"<p>I previously wrote about how after successfully downgrading APEX users still get the error &#8220;Application Express is currently unavailable&#8221;. I now ran to the same issue again, with newer versions and the procedure how ORDS detects is APEX is currently being patched has changed. This post is about downgrading to APEX 23.1 and ORDS 24.1. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[21,66],"class_list":["post-763","post","type-post","status-publish","format-standard","hentry","category-blog-entry","tag-apex","tag-ords"],"_links":{"self":[{"href":"https:\/\/ilmarkerm.eu\/blog\/wp-json\/wp\/v2\/posts\/763","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ilmarkerm.eu\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ilmarkerm.eu\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ilmarkerm.eu\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ilmarkerm.eu\/blog\/wp-json\/wp\/v2\/comments?post=763"}],"version-history":[{"count":2,"href":"https:\/\/ilmarkerm.eu\/blog\/wp-json\/wp\/v2\/posts\/763\/revisions"}],"predecessor-version":[{"id":765,"href":"https:\/\/ilmarkerm.eu\/blog\/wp-json\/wp\/v2\/posts\/763\/revisions\/765"}],"wp:attachment":[{"href":"https:\/\/ilmarkerm.eu\/blog\/wp-json\/wp\/v2\/media?parent=763"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ilmarkerm.eu\/blog\/wp-json\/wp\/v2\/categories?post=763"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ilmarkerm.eu\/blog\/wp-json\/wp\/v2\/tags?post=763"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}