On 1/13/22 8:15 AM, Achilleas Mantzios wrote: > On 13/1/22 4:12 μ.μ., Kenneth Marshall wrote: >>>> Hi Achilleas, >>>> I would go with version B - since as I understand it's ISV >>>> solution. Meaning the postgres ddl was tested and aligned with the >>>> application layer, otherwise you would need to fix app layer after >>>> the migration. >>> Dziekuje Alicija. The powerbuilder app is in-house developed, source >>> is available, what could be wrong with the app? Browsing through the >>> powerbuilder source I don't see (by eye) anything that could break >>> something in PgSQL. >>> -- >>> Achilleas Mantzios >>> DBA, Analyst, IT Lead >>> IT DEPT >>> Dynacom Tankers Mgmt >> Hi Achilleas, >> >> If the schema and usage is straight-forward, I would recommend using >> ora2pg to give you an estimation cost for your migration by letting you >> know what cannot be automatically translated. Once you have that you >> will be better informed as to the work needed. > Thank you Ken!
ora2pg worked perfectly for us in migrating 8TB of Oracle 11 data and simple triggers to Pg 12.
-- Angular momentum makes the world go 'round.
Just to be clear. There are 2 options:
1. ISV solution that supports both postgres and oracle when you have the code and db layer aligned to both dbs. In this case it makes no sense to migrate yourself with ora2pg - then you will be reinventing the wheel and waste a lot of time for app, db migration and testing. And what will happen when you will want to upgrade the your app? You want to merge/compare the code? do the testing? do you really want to waste your time for it?
If you have ddl for postgres shipped by your vendor all you need to do is data migration.
2. in-house built soft - then ora2pg is your friend