moving from Oracle to SQL Server

[Anon Anon]

Hello all

Have tried searching on this to no avail so here's my first new thread!

Having finally installed Clarity 12.1.0.5849 I now have to migrate from Oracle to SQL Server.

The source Clarity is v12.0 but not sure about Oracle (from Clarity requirements I presume 10 or 11?). Am going to v12.1 with SQL Server 2008.

Is it a straightforward job to bring this across? Or perhaps in other words, does it matter which database vendor I move from and to so long as it's either Oracle or SQL Server?

If this is a stupid question then that'll be me asking it!
;-)

Thanks

[Anon Anon]

How are you planning to do the migration?

I would imagine its pretty hard (and unsupported) to be do doing it at a pure database level....

But a migration via the application interfaces (i.e. XOG-ing out the data from one environment and XOG-ing into the other) would be supported and would work; it might well be a pain to work out what order you need to do all the XOG-ing in though!

You should not have problems using XOG across with the slightly different Clarity versions (12/12.1); but, as with all things, you need to test / QA everything you do!

[Anon Anon]

Hi Dave

Thanks for your reply.

Yes, I should have mentioned that it would not be at db level.

When you say a pain sorting out the order though, is that because of the move between Oracle and SQL Server or would it be the case in moving any database, even if they are both Oracle or both SQL Server?

Cheers
Pete

[Deactivated User]

I agree there are more rewarding challenges than doing the migration at db level.

One sorting order is in the thread Best practises
17149122

There is no single truth and many times you don't do just one write of each type of file because of the dependencies and relations.
Like you can first jsut create the users and resources, then create the OBS and FOS and then write the resources again with the associations.
The same way with users and groups.
That is not a problem or too much work.

The areas where you have more work are the ones which cannot be written with XOG like time reporting periods, time slice definitions, job schedules,
calendars and non working days. Note also that both read and write are not supported in all cases.

Martti K.

[Anon Anon]

Pete - no the "pain" is nothing to do with the DB versions, just sorting out the "Clarity dependencies" between the data. Doing a migration like this should be the same as if you were on the same DB.

(and the thread Martti is referring you too should give you a start on the right order etc)