I'm moving database from Oracle to SQLServer (2012 if that matters). The process of migrating tables/views is more or less straightforward and automated. Triggers are also not an issue since I don't have too many of them.

However, I wonder what is the best practice for moving Oracle packages. As far as I know, SQLServer doesn't have anything similar. My idea is to map each package to SQLServer schema (thus, for instance, I'll have 'package1' , 'package2', etc schemas in SQLServer, each of them has no tables, just functions/procedures/types). I believe it will preserve original purpose of packages and at the same time reduce number of changes required on application side.

Does it make sense or I'm on a wrong way?

Thank you.

  • When migrating the triggers, don't forget that SQL Server doesn't have row level triggers, only statement level triggers. – a_horse_with_no_name Jun 22 '13 at 21:42

There is a similar Stack Overflow Post on the subject. Your idea of mapping Oracle packages to schemas in SQL Server is the approach deemed most directly analogous.

  • 1
    Welcome to DBA.SE. This is more of a comment than an answer, unless you can provide more than just "that makes sense". Maybe surmise what the SO link your provided speaks about? – user507 Jun 23 '13 at 0:55
  • Agreed and edited. Reputation score is insufficient to comment on the original question. – Robert Gannon Jun 23 '13 at 3:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.