1. November 6

    Hi Marco,
    It is a good practice to create an export for an application (not workspace) when you want to distribute it. When you navigate to Shared Components there is a link “Manage Supporting Objects” to the far right. There you can define all the tasks you complain about (prerequisites, validations, installation scripts etc). You should try that.
    BTW The last link in your post doesn’t seem to work.

  2. November 6

    There is were the “newbie” part comes in, although my gut feeling says that the option you mention is probably not good enough for, for example, checks and grants executed via the SYS user.

    On the other-hand, maybe Mark and I are still to illiterate on the subject and I got the wrong files delivered 😉

  3. November 6

    Hi Marco,

    Did you already look at the Supporting Objects feature? That allows you to essentially include scripts (to check for the existence of objects, create objects, seed data etc)? You can also include pre-requisite checks for the application etc.

    Obviously it can’t do anything like granting permission to you (as that would need to be done via the usual DBA grants etc), although I think a lot of what you mention is already available for Supporting Objects.


  4. November 6

    No John, on this part I disagree. The Supporting Objects part is the part that lacks possibilities, and possibilities are the ones, I am not complaining about, but want, if possible, some more sophisticated methods for.

    My car has windows and years ago it had a knob that would able you to open the window. What I am asking for is a knob that I can push so that the process is automated. There is a difference, especially if it prevents faults / enables a more fault tolerant set-up

    Thats why I called it “an enhancement” request. I am a newbie on APEX and the writings here are my experiences so others can avoid my “mistakes”. In all, there is room for APEX improvement, right?

  5. November 6

    Hi Marco,

    Perhaps my comment came across wrong? I certainly don’t disagree with –

    “In all, there is room for APEX improvement, right?”

    Absolutely…100% agree with that, you’ll hear no complaints from me on that one (and there are some huge changes coming in 4.0).

    At ODTUG I also discussed with Joel Kallman that I’d like to see the Supporting Objects be more declarative, rather than the manual task that it is right now. For example, it would be very nice if APEX included the current version (using DBMS_METADATA this is trivial) of your packaged code when you exported it, rather than a version from 3 months ago that you forgot to manually update.

    Again, I don’t disagree with you one bit that the situation could be simplified. But as I hadn’t seen mention of Supporting Objects in your original post I wasn’t sure if you were already aware of it or not.

    Also, for some reason my post didn’t appear on your blog until after Roel etc had replied (even though there were no other comments when I posted it)…so perhaps that added to a bit of confusion 😉


  6. November 6

    No worries 😎

    For me its my first real adventure with APEX so I just am trying to write it down “as it feels”… all good suggestions for this newbie are appreciated…

  7. Michael Roessler
    November 7

    In my opinion we seem to be addressing two separate issues as one. Perhaps we could simplify by separating them?

    1) You would like to see added functionality in APEX, and,

    2) You would like to successfully export and import the XFILES application to begin further work on it.

    Let’s find a method of allowing #2 to progress at a rate faster than #1.

    Now, I may have misunderstood so jump in and correct me if needed – but it seems to me as though you are challenged to identify all the database objects required to run XFILES in its current form. Perhaps this is made more challenging by the inability to ask the original author just how he built the app – so you get stuck in a situation where dependent database objects across multiple schemas are hard to identify and include in an export. You are therefore relying on APEX to discover for you and export automatically all those unidentified, dependent database objects.

    An APEX application is just a (smart) method of exposing data/sql/plsql in the database. The XFILES application as developed may not be aware of certain dependency relationships among the database objects or initialization parameter requirements for XML DB.

    This may indicate that the first step before running the XFILES app in a new workspace/database is to rediscover manually those dependency requirements.

  8. November 8

    I see myself as proficient in dealing with database issues since I started off with Oracle V6 and have been a DBA since (including fiddling around and/or managed UNIX systems, the first Oracle Web Servers V2 and onwards, including the first “APEX” offspring, like the “Oracle Web Server killer” and HTMLDB, etc)

    So yeah, I know what you are trying to explain and yeah, I still think that there is room for improvement and yeah I really like APEX, but I know what I am talking about and it could be implemented more efficient.

  9. Michael Roessler
    November 9

    Indeed you are knowledgeable and experienced. I think we all believe you know what you are talking about. Your input into APEX would surely be useful in future iterations. I simply thought that by focusing on the XFILES app and its implementation as a goal separate from improving the future of APEX could assist your goal of building a packaged app around XFILES. My input is intended to assist your goal, not challenge it.

    Best regards.

  10. November 9

    I knew/thought so, but I just wanted to wanted to clarify my position.

    I don’t want to spend too much time on “proving that I like APEX”, during every small piece of criticism or enhancement proposal that pops in my mind while working with this 3.2.0 version (standard issue Oracle V11. 43 bit on Linux)

Comments are closed.