View previous topic :: View next topic
|
Author |
Message |
Madhubalan Periyasamy
New User
.jpg)
Joined: 09 Aug 2021 Posts: 1 Location: Sweden
|
|
|
|
Has anyone worked on a project where you have written a code with similar specifications writtten below?
If yes, can you share your experience on how good or bad this is compared to the traditional approach of embedding the SQL directly in a module?
SPEC:
Lets assume that we have a table called EMPLOYEE. and an application written in COBOL.
Instead of embedding the SQL to access this table in every program that has to access this module, we create a sub-module that contains all possible SQL statements (SELECT,UPDATE,DELETE, INSERT) used on that table.
So whenever there is a need to access this table, we just call the sub-module with enough input. |
|
Back to top |
|
 |
prino
Senior Member

Joined: 07 Feb 2009 Posts: 1318 Location: Vilnius, Lithuania
|
|
|
|
Typical imbecile PHB idea. |
|
Back to top |
|
 |
Rohit Umarjikar
Global Moderator

Joined: 21 Sep 2010 Posts: 3077 Location: NYC,USA
|
|
|
|
It really doesn’t matter , update , delete operations may have different where conditions which you cannot achieve thru one module unless you build dynamic sqls.
Second , it’s easier and flexible to control sqls if you write your own in the program as per requirements and it works pretty well.
Only in case of vsams I have seen using one I/o module to perform all such operations as it was critical to the application and it’s easier to manage by one module than many programs plus buffering , performance , contention issues reduce to almost none using one module. |
|
Back to top |
|
 |
prino
Senior Member

Joined: 07 Feb 2009 Posts: 1318 Location: Vilnius, Lithuania
|
|
|
|
If you want replies ask for them here, not in PMs, unless you yourself are the PHB. |
|
Back to top |
|
 |
sergeyken
Senior Member

Joined: 29 Apr 2008 Posts: 2159 Location: USA
|
|
Back to top |
|
 |
|