Skip to Main Content
  • Questions

  • Migration of Packages,Procedures, Function etc

Breadcrumb

Question and Answer

Chris Saxon

Thanks for the question, Nitesh.

Asked: October 12, 2017 - 8:35 am UTC

Last updated: October 12, 2017 - 2:41 pm UTC

Version: 6i

Viewed 1000+ times

You Asked

Hi Team,

I am working on a application that is built using designer of forms and reports 6i.

As we know 6i has already out of support.

Now we need to migrate it to some new technology a web-based will be preferable.

But the new demand from application owner is that they need all business logic that is currently stored in form of functions,procedure & packages in DB to be now embedded in code itself(i.e. use DB only to store data).

It would be of great help if you suggest some of the technology of Oracle in which such migration can be possible.

But also you can suggest if the technology will provide some in built tool to migrate existing functions,procedure & packages in to it.

Your expert suggestions would be really of great aide to me.

Thanks in advance.

Regards,
Nitesh

and Chris said...

Hang on.

So you have a load of "business logic" code in your database packages etc. And the application owner want to rip all that out and move it to the application level?

Why exactly?

That's a lot of effort for questionable benefits at best.

As we've discussed in the past, making full use of PL/SQL is the way to go:

https://asktom.oracle.com/pls/apex/f?p=100:11:::NO:RP:P11_QUESTION_ID:9535371900346546659
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:9526787800346856323

Anyway, back to your question.

I'm not aware of any tool which will help with this migration. I'm not sure something like this is even possible.

If none of the PL/SQL called by your app has any dependencies (i.e. every call from your Forms only access PL/SQL procedures/functions which themselves don't call other PL/SQL packages etc.) then you could paste all the PL/SQL directly into the database calls of your new application as anonymous blocks.

But this is unlikely.

It's much more likely you have a mass of dependencies (Form A calls package B, which calls packages B, C and D and so on). Converting this to another language will be a massive effort for any non-trivial application.

Keep your code in the database. Choose your new front end technology and reuse your existing investment.

If you're looking for a way to convert the Forms themselves, check out Application Express (APEX).

We have a documented process to migrate from Forms -> APEX at:

https://docs.oracle.com/database/apex-5.1/AEMIG/how-to-convert-application.htm#AEMIG166

Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Thanks

Nitesh Panchal, October 12, 2017 - 2:22 pm UTC

Hi Chris,

Thanks for your valuable inputs.

We were indeed looking at APEX for the migration.

But it being on 6i we need to fix all the obsolete and unsupported calling in codes.

So we had plan to migrate 6i-->10g-->APEX.

But due some demands from application owner ,we had to stall this approach.

But with your suggestion we would put emphasis on the migration towards APEX.

Thanks Again.

Regards,
Nitesh
Chris Saxon
October 12, 2017 - 2:41 pm UTC

Good luck, hope you manage to get migrated to APEX safely :)
more

Connor and Chris don't just spend all day on AskTOM. You can also catch regular content via Connor's blog and Chris's blog. Or if video is more your thing, check out Connor's channel and Chris's channel from their Youtube channels. And of course, keep up to date with AskTOM via the official twitter account.

More to Explore

PL/SQL demos

Check out more PL/SQL tutorials on our LiveSQL tool.

PL/SQL docs

PL/SQL reference manual from the Oracle documentation library