For many years when the build of the app was built with Oracle forms, reports etc customers had access to the source files which allowed for amongst others 1 key thing which I believe helps promote the use of Oracle Apps:

1) Customers who employ technical people can determine exactly how something works and also importantly how it does not.

There are still many people in the ICT business and I am sure always will be who will spend their own time be they employees, non-employees clarifying how a process has been designed to work and who then pass that knowledge onto others.

The user guides with an application/piece of s/w can only cover so much and do not always provide detail on a process and the relationships with other processes. This can cost a lot of time.

So this would be my big wish.

As the range of technologies employed ever expands and as defacto stds do get established for many reasons, a common goal from the past of open systems/ common platforms in a competitive fast moving area are probably still unlikely while software and other is purchased. So when a vendor adopts new technolgy in a product it benefits all if users can see how it is has been applied. You do not need to be a java expert to read and understand how java has been used and what it does. By doing so people also improve and extend their knowledge which further promotes the use of the technology.

So I think that Oracle should provide all source code for application based objects except for some that are crucial for business reasons/ core property rights.

This will as in the past expand the knowledge of the Oracle community which in turn directly benefits Oracle as the resource pool quality improves and so customers considering ERP/technology stacks etc as standards, are more likely to continue to choose a vendor who provides the opportunity to companies and individuals to become quality Oracle users and providers.

You can log a SR and get assistance but sometimes you need to know how something ‘really’ works.

1. There is a high and continuous redo log generation inspite of tuning the streams_pool_size parameter. Initial design of sizing the offline relog log file space goes havoc.

2. Simpler handlers to be introduced as this is plus point of streams so as to pre-calculate and store data into tables.

3. Performance issues and high cpu conusumtion as there is a continuous backgroud job queue process running.

4. Continuous logs being written.

If we could set a time interval where the queue process could wake and replicate data it would benefit, queue process then should be stopped.. The same goes to scns.
Log files to be generated only based on some time interval.

1) customers should be payed money if they run into bugs that disrupt their business transactions (and for the time spent by internal or external consultants to troubleshoot and find workarounds)
2) all packs for free for everyone but most importantly provisioning pack which can ease the pain of patching
3) not play hide and seek when important security issues have been reported that won’t be fixed in the near future (eg 6454409 LISTENER LOCAL OS AUTHENTICATION CAN BE BYPASSED..)
4) no need to tune the self tuning, manage the self managing
5) AI in the rdbms kernel so it can learn