COBOL, PL/SQL, or both

On Thu, 19 Sep 2002 13:28:44 GMT, spamdump_at_nospam.noway.nohow (Ed Stevens) wrote:
>>I would also stick all the updated data into a PL/SQL collection
>>(probably an index-by table) and then use the FORALL to loop through
>>all the UPDATE statements. It's much faster than doing a separate
>>UPDATE for each changed row.
>>
>>John
>
>A nice technique, but would that not require that the application be written in
>PL/SQL? If so, I refer you back to the original post -- the app is written in
>cobol and the project is to port it to a different platform.

Oops, I did overlook that, what with the pseudo-code. I tend to mentally translate it always to PL/SQL. :-)

However, it might still be practical to embed a PL/SQL anonymous block to do the core of the update loop, assuming that's a relatively simple and self-contained bit of code. Pro*COBOL supports embedded PL/SQL:

http://otn.oracle.com/docs/products/oracle8i/doc_library/817_doc/appdev.817/a76951/pco06pls.htm#3835

On a slight tangent...

I'm interested in the notion of transitioning from other languages to PL/SQL, or integrating PL/SQL into an application that's mostly written in something else, e.g. via embedded PL/SQL or stored procedures.

Some of the new 9i features put me in mind of the similarities between Perl and PL/SQL (associative arrays, nested collections, HERE documents). I guess users of other languages find their own similarities and differences when they first take a look at PL/SQL.

John Received on Thu Sep 19 2002 - 21:00:38 CDT