| Clark F Morris 2007-10-10, 9:55 pm |
| On Wed, 10 Oct 2007 16:35:49 -0600, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:
>< GemdnaPKRcdMgpHanZ2dnUVZ_tLinZ2d@comcast
.com>, LX-i<lxi0007@netscape.net>
>wrote:
>
>I don't know. I guess since they support instantiating Java objects from
>within COBOL you could use JDBC.
>
>I don't understand the reasoning behind your second statement, though. It
>seems to me (without having actual tried it!) that it would be desirable to
>have a database access class containing EXEC SQL statements. That is if
>you're stuck using static SQL, which I know Pete always comes out against.
>(I don't have enough experience to have an opinion on that matter).
Back in the 1998 - 1999 timeframe I was on a Year 2000 project. The
client decided to move their ledger and other accounting to Oracle
Financials on AIX boxes. Another group was working on that and an
outsourcing company was involved. There were sever performance
problems and when the consultants attached to the Year 2000 project
investigated, they found dynamic SQL was being used. Switching to
static SQL apparently got rid of much of the performance problem.
Since this is second hand from one of those involved, I am sketchy on
the detail but I suspect it may in part have to do with bind and
parsing overhead. Those who are really into data base probably can
explain the trade-offs and technical issues far better than I can.
>
>Assuming that you were working with mainframe COBOL and you, for whatever
>reason, are not using JDBC for database access, what type of OO methodology
>and database access would you use? I assume (perhaps erroneously!) that
>coding EXEC SQL statements in the main body of each program is not the best
>OO way to go. Then again, perhaps it is?
>
>Frank
|