1

I am migrating Pro*COBOL and Pro*C (code with embedded SQL) to Java.

Am I right that I should move migrate all of the embedded SQL to JDBC calls?

Or is there a sort of "Pro*Java" way that Oracle would recommend? What is the usual best practice?

Mat
  • 202,337
  • 40
  • 393
  • 406
Nicolas Raoul
  • 58,567
  • 58
  • 222
  • 373

2 Answers2

2

Yes.

There was (or is?) SQLJ for embedding SQL into Java, but I have never seen that in use anywhere.

Everything SQL-based in Java goes via JDBC.

A usual practice (not sure if a "best practice") is to abstract even further and use an ORM and some kind of persistence API.

Thilo
  • 257,207
  • 101
  • 511
  • 656
  • 3
    I would not call ORB a "best practice". It might be an easy way out of the problem of Java-RDBMS communication, be it is (almost always) inefficient (my opinion is that Hybernate is horribly bad). My suggestion is stored procedures: keep all db related work inside the db. Not only it allows teh most efficient implementation (all the optimization Oracle can do with cursors), but also it allows a high level of independence. E.g. if all the data manipulation logic was developed in stored procedures then switching from Cobol and C to Java would be a trivial task (at client-db communication level) – Szilard Barany Feb 28 '12 at 06:17
0

As there is no easy way to migrate C or worse COBOL to Java you will be doing a lot of re-writing anyway. So using JDBC with your existing SQL is probably the easiest way to go.

Another poster mentioned SQLJ which is a possibility, however I don't think it really gains you anything as you will be doing so much re-factoring anyway, however if you are happy with the whole pre-compiler thing then it will work! (At least for Oracle or DB2, support is patchy for the freebie databases).

James Anderson
  • 27,109
  • 7
  • 50
  • 78