Converting from DB2 to Oracle
TUCKERH
applications datebase source from DB2 to Oracle
Dan Antion
wasn't that bad. I don't know how you map DB rows to objects, but since
we have such a small database, we do it manually for each appilcation.
Once we discovered the differences, it was simply an excercise in
chasing down the little bits that had to be fixed. For example, We had a
few select statements where we were using Oracle's DECODE function, and
those had to be rewritten using CASE. Also, Oracle had a psuedo ROWID
that you can use in an update statement nut DB2 didn't, so for simple
tables that didn't have a unique key, we had to add one to the DB2
table. We just added a sequence and we were fine. These were easy to
find using VaAssist.
As far as VAST goes, there really weren't any problems. The connection
to both Oracle and DB2 are native, so you should only have to change the
connection itself, not your code. Our biggest issues were the SQL
differences and the different datatype options between the two DBs.
Good luck,
Dan
----------------------
Dan Antion
American Nuclear Insurers
Michael Voss
TUCKERH wrote:
> Can anyone give me a heads up on the complications when converting a VA
> applications datebase source from DB2 to Oracle
As Dan mentioned, our issues when migrating our VA Apps from DB2 to Oracle
were mostly dealing with different sql regarding Date/Time/Timestamp fields
and the handling of empty strings (IIRC, Oracle treats empty strings as null
values, so you cannot insert an empty string into a NOT NULL field).
HTH
Michael
Ivaylo Mutafchiev
used. It depends on the complexity of your application(s) and how
deep/slight it/they depends on the particular database - means did you used
SQL92 standard in your statements or wrote them using a sql dialect of the
particular db engine. As far as I remember DB2 supports SQL99 since some
version, don't know about Oracle.
For us it was quite complex to migrate from DB2 to another db-engine (not
Oracle), and to support both db engines further. We had enough stored
procedures written on C (it was early DB2 v.6.0).
Ivaylo
G.S. Link
> Can anyone give me a heads up on the complications when converting a VA
> applications datebase source from DB2 to Oracle
>
>
problems start if you use some of the more advanced features of DB2.
Federation, distribution and advanced statistics will cause recoding
especially if you were pushing them in DB2. This is also true for
triggers, stored procedures and UDFs. User implemented backup strategy
can also be a problem.
Dan Antion
G.S. Link wrote:
Again, we were going from Oracle to DB2, but stored procedures and
triggers didn't give us much grief, although we didn't use many.
Can you explain what you mean by user implemented backup strategy?
Dan
G.S. Link
in ways other than the regular backup strategy. An example would be a
transaction that was not committed when the system crashed. Another
example would be real time protection against things such as an attack
on your data center. If you fool with DB2 so you are using recovery in
ways that bypass IBM recovery then it probably won't work with Oracle.
An example of this is the user who puts his recovery on a virtual
container and then replicates it at a remote site. The result is not
readable by Oracle. I know of one bunch that actually did this, believe
it or not.
A problem going the other way is a case of dropping a field from a
table. This could and likely would be the cause of considerable
tinkering in DB2 and is easy to do in Oracle. Some people stretch their
databases and this will be a problem in DB2 to Oracle. Simple straight
SQL is going to work on either system without change. Most of the built
in functions will also work.