7 Replies Latest reply on Dec 18, 2013 12:15 AM by Scott Wesley

    Oracle APEX 4.2.2 - On-demand Application process cannot exceed 30,000 bytes.

    jstem1177

      Hello All,

       

      Just came accross this error!. Can anybody tell em if its fixed in 4.2.3 or how I can fix this.

       

      Error: "Application process cannot exceed 30,000 bytes."


      Yes I have one massive on-demand process and it needs to be an on-demnad process, so I'm very relunctant to move it to a stored procedure.

       

      Sincerely

       

      Jan S.

        • 1. Re: Oracle APEX 4.2.2 - On-demand Application process cannot exceed 30,000 bytes.
          fac586

          jstem1177 wrote:

           

          Just came accross this error!. Can anybody tell em if its fixed in 4.2.3 or how I can fix this.

          Doubt that it will be regarded as something that requires fixing.

          Yes I have one massive on-demand process and it needs to be an on-demnad process, so I'm very relunctant to move it to a stored procedure.

          Why? What difference will it make? (Other than improving things by applying best practice.)

          1 person found this helpful
          • 2. Re: Oracle APEX 4.2.2 - On-demand Application process cannot exceed 30,000 bytes.
            Denes Kubicek

            Avoid writing your code into the application. Use packages - functions and procedures.

             

            Denes Kubicek

            -------------------------------------------------------------------

            http://deneskubicek.blogspot.com/

            http://www.apress.com/9781430235125

            https://apex.oracle.com/pls/apex/f?p=31517:1

            http://www.amazon.de/Oracle-APEX-XE-Praxis/dp/3826655494

            -------------------------------------------------------------------

            1 person found this helpful
            • 3. Re: Oracle APEX 4.2.2 - On-demand Application process cannot exceed 30,000 bytes.
              jstem1177

              Hello Denes,

               

              Thank you for the info. However, how do i deal with application updates?

               

              Here is an example: I update a package and some on demand process. I deploy the new version of my application and send it to a client. He simply drops the older version and imports the new one. With your suggestion, he also needs to import the package, yet that customer knows absolutely nothing about oracle databases.

               

              My reason for the on-demand process, is to minimize this extra setup. But I do understand your point. I suppose I could write up a package (interface to my application, "Update software" which would allow the user to upload a file to the server and call an external command to run the *.sql file....

               

              Still, I don't see what is the big deal. So much for BIG DATA. Why not allow 10MB of data into a simple on-demand process. The update process would be so much easier.

               

              But maybe, i need to evaluate the "update" process.

               

              Thanks

               

              Jan S.

              • 4. Re: Oracle APEX 4.2.2 - On-demand Application process cannot exceed 30,000 bytes.
                Mike Kutz

                Hmm... if there were only a way to include update scripts within the application

                (hint : it is under "Supporting Objects")

                 

                MK

                • 5. Re: Oracle APEX 4.2.2 - On-demand Application process cannot exceed 30,000 bytes.
                  jstem1177

                  Hello mike,

                   

                  Thanks. Will look into that and make the necessary adjustments to my application design. However, is there not a eprformance loss when I call an on-demand-process which then calls a store procedure?

                   

                  On the other hand, I believe its possible to call a stored procedure directly from a "Ajax" call by granting execute to apex_public_user on the stored procedure, but that might open up some security issues.

                   

                  Thank you all for your insight.

                   

                  Jan S.

                  • 6. Re: Oracle APEX 4.2.2 - On-demand Application process cannot exceed 30,000 bytes.
                    Mike Kutz

                    However, is there not a eprformance loss when I call an on-demand-process which then calls a store procedure?

                    With 30k+ bytes of code, just the opposite. (ie it is more performant to call compiled code.)

                    Remember, the text that you see for "Source" is ran in the database by going through DBMS_SQL.parse().

                    That text is not compiled but the the code in a package is.

                     

                    granting [any permission of any type] to apex_public_user

                    BAD IDEA !!!

                    The ONLY privilege this account should have is CREATE SESSION.

                     

                    I believe its possible to call a stored procedure directly from a "Ajax" call

                    I'm sure this is possible.  But, I feel this is off-topic compared to your original problem.

                    If you are wondering how to call a procedure from within a process.... just call it.

                    myschema.mypackage.myprocedure( :P1_bind_var_one, :P1_bind_var_two, :P1_etc_etc );

                     

                    MK

                    • 7. Re: Oracle APEX 4.2.2 - On-demand Application process cannot exceed 30,000 bytes.
                      Scott Wesley

                      I will also confirm what Mike, Denes and Paul are saying. I performance tested plugins recently and found by moving the package source from the plugin to a database package improved performance by upto a one order magnitude. (blog post coming soon). All by something already recommended in the attribute help

                      Enter a PL/SQL anonymous block of code that contains function for rendering, validating, execution and AJAX callbacks for the plug-in.

                       

                      For performance reasons you can also store this code in a PL/SQL package in the database.

                       

                      And I also have a word of caution regarding this statement:

                      He simply drops the older version and imports the new one.

                      What if something went wrong with the new version? - you've just dropped the old one.

                      You can very easily version your application with the use of application aliases. Unless of course you're simplifying your problem.

                       

                      Large, poor performing, hard to maintain is big CODE, not big DATA.