Code Comments
Programming Forum and web based access to our favorite programming groups.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. >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 an d >I think that's a good thing...). There are many other reasons... >
Post Follow-up to this messagePowered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.