| Clark F Morris 2007-10-11, 9:55 pm |
| On Thu, 11 Oct 2007 16:59:45 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>
>
>"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
>news:470CFF65.6F0F.0085.0@efirstbank.com...
>
>Slight correction, Frank.
>
>It is EMBEDDED SQL I'm trying to move away from, not static. As both static
>and dynamic SQL can be embedded in COBOL I needed to make this point. (I am
>not necessarily in favour of using only dynamic SQL; that decision needs to
>be taken on a case-by-case basis...)
>
>For most COBOL people the option is either:
>
>1. Use stored procedures, with only triggers embedded in COBOL code.
How you use stored procedures? How difficult would it be to change
existing embedded SQL to use the stored procedures? Is there a net
increase in CPU or other resource used? The idea sounds good and
might get around some of the frustrations I have had in my limited use
of SQL in COBOL.
[color=darkred]
>2. Embed full SQL into COBOL as we have traditionally done since 1983.
>
>In this scenario I favour option 1, for too many reasons to go into here,
>but lack of impact on COBOL code if the RDBMS is changed or upgraded, is a
>major one. (It means the conversion is "outside" of the application code and
>I think that's a good thing...). There are many other reasons...
>
|