View previous topic :: View next topic
|
Author |
Message |
amol.kulkarni05
New User
Joined: 05 Feb 2008 Posts: 2 Location: pune
|
|
|
|
i know it is advisable to use DCLGEN variables in the query instead of working storage variables.
but why cant we use working storage variables in the query? |
|
Back to top |
|
|
vasanthkumarhb
Active User
Joined: 06 Sep 2007 Posts: 275 Location: Bang,iflex
|
|
|
|
Hello,
When you extract the values or datas from the Table using SQL the values are feeded to DCLGEN variables first. So DCLGEN must be used when passing variables to working-storage variables, for further caluculation. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
|
|
Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
|
|
|
|
vasanthkumarhb wrote: |
Hello,
When you extract the values or datas from the Table using SQL the values are feeded to DCLGEN variables first. So DCLGEN must be used when passing variables to working-storage variables, for further caluculation. |
WRONG |
|
Back to top |
|
|
stodolas
Active Member
Joined: 13 Jun 2007 Posts: 631 Location: Wisconsin
|
|
|
|
You can use working storage instead of the DCLGEN. It is just advised to use the DCLGEN for various reasons, among them everything is then named consistently between the database and your program. |
|
Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
|
|
|
|
And the variables are properly defined! |
|
Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006 Posts: 1050 Location: Richmond, Virginia
|
|
|
|
Perhaps we should say why vasanthkumarhb is WRONG:
A SELECT or FETCH quite clearly states the host vars into which the results are to be populated.
amol - your question also is not quite clear. You (correctly) state that it is "advisable" to use DCLGEN vars, so assuming you know what "advisable" means, you should not be asking "why can't we use..." [my bold], because clearly we can.
Also - DCLGEN vars are working-storage - the compiler doesn't know any difference between them and any other w-s var, because there is none, other than how they got there.
Finally, there might be times when my DCLGEN vars hold the last row SELECTed or FETCHed, but I need one or more cols from another row. I find it cleaner to use other vars for this ancillary access. |
|
Back to top |
|
|
amol.kulkarni05
New User
Joined: 05 Feb 2008 Posts: 2 Location: pune
|
|
|
|
Phrzby Phil wrote: |
Perhaps we should say why vasanthkumarhb is WRONG:
A SELECT or FETCH quite clearly states the host vars into which the results are to be populated.
amol - your question also is not quite clear. You (correctly) state that it is "advisable" to use DCLGEN vars, so assuming you know what "advisable" means, you should not be asking "why can't we use..." [my bold], because clearly we can.
Also - DCLGEN vars are working-storage - the compiler doesn't know any difference between them and any other w-s var, because there is none, other than how they got there.
Finally, there might be times when my DCLGEN vars hold the last row SELECTed or FETCHed, but I need one or more cols from another row. I find it cleaner to use other vars for this ancillary access. |
Thanks for giving valuable responses.
actually i wanted to ask that what parameters are affected when we use working storage variables rather than DCLGEN variables in DB2 queries?
Why it is advised to use DCLGEN variable in the DB2 query? |
|
Back to top |
|
|
ksk
Active User
Joined: 08 Jun 2006 Posts: 355 Location: New York
|
|
|
|
No parameters will get effected when you use Working-storage variables instead of DCLGEN variables.
Possible syntax errors are high,as per my knowledge,when you use Working storage. DCLGEN is system generated, so no syntax errors would occur.
KSK |
|
Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006 Posts: 1050 Location: Richmond, Virginia
|
|
|
|
Again - DCLGEN vars are in working-storage, as are all vars, I think, except for the few in LINKAGE.
DCLGEN is just a convenience to generate a COBOL record guaranteed to match your table. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
|
|
|
|
amol.kulkarni05 wrote: |
actually i wanted to ask that what parameters are affected when we use working storage variables rather than DCLGEN variables in DB2 queries? |
Hi,
Did You want to say that if one defines the same table definition, same as by DCLGEN but with 'different names', then can those 'different-variablea' be used in program or not? |
|
Back to top |
|
|
acevedo
Active User
Joined: 11 May 2005 Posts: 344 Location: Spain
|
|
|
|
In my humble opinion the real reason is:
Craq Giegerich wrote: |
And the variables are properly defined! |
|
|
Back to top |
|
|
dr_te_z
New User
Joined: 08 Jun 2007 Posts: 71 Location: Zoetermeer, the Netherlands
|
|
|
|
acevedo wrote: |
In my humble opinion the real reason is:
Craq Giegerich wrote: |
And the variables are properly defined! |
|
Yes. That's because you do not notice, but DB2 does. Has to do with stage-1/stage-2 predicates. End result is the same but the database performance is worse. As from V8 all this becomes less critical, but programming standards like that were created in the stone-age. |
|
Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006 Posts: 1050 Location: Richmond, Virginia
|
|
|
|
dr_te_z:
Please clarify your comments. Thanks. |
|
Back to top |
|
|
dr_te_z
New User
Joined: 08 Jun 2007 Posts: 71 Location: Zoetermeer, the Netherlands
|
|
|
|
Phrzby Phil wrote: |
dr_te_z:
Please clarify your comments. Thanks. |
suppose you code
Code: |
select col1 from tab1 where col2 = :my-own-ws-field |
when col2 is defined in db2 as char(8) and you define my-own-ws-fiels as pix x(9) everything seems okay, but they do not match exactly.
When there is an index defined on col2, DB2 might not use it. When you use a host-variable which is exaclty the same format, db2 will use the index.
As from V8 DB2 is smarter in choosing an index or not, but still. |
|
Back to top |
|
|
|