some doubt in SELECT * in embedded SQL, DATE,TIME,TIMESTAMP

mijanurit · New User Joined: 26 Aug 2005 Posts: 33 Location: bangalore

hi all,

i have some doubt regarding some question in DB2.
plz explain these question in detail.
questions are

1. why SELECT* is not preferred in embedded SQL?

2. what are the issues related with correlated subqueries?

3. give the COBOL Definition of a VARCHAR field?

4. THE PHYSICAL STORAGE LENGTH OF DATE,TIME,TIMESTAMP ARE 4BYTES,
3BYTES,10BYTES RESPECTIVELY.
But their cobol picture clause are DATE-->pic x(10), time-->pic x(8)
timestamp-->pic x(26).

here x(10) means 10 characters i.e 10 bytes.
x(8) means 8 characters i.e 8 bytes.
x(26) means 26 characters i.e 26 bytes.
then what is the compatibility between physical storage length of these three datatypes
and picture clause declared in cobol?

thanks in advance

regards
mijanurit

balusengodan · New User Joined: 01 Mar 2005 Posts: 15 Location: chennai

hi mijanurit,

select * is not used in embedded sql because other can also view, select, update the same table. so it will lead to some error values thats why it not used . where as there is high risk of loosing our data

thank
balu

prabs2006 · Active User Joined: 12 Jan 2006 Posts: 103

Hi

1. why SELECT* is not preferred in embedded SQL?
If multiple rows are retrieved how will you store the values.This is not advisble

2. what are the issues related with correlated subqueries?
Efficiency, as it needs to back and forth to get the result

3. Give the COBOL Definition of a VARCHAR field?
Varchar(N) - 01 NAME.
49 NAME-LEN PIC S9(4) USAGE COMP.
49 NAME-TEXT PIC X(N).

4. THE PHYSICAL STORAGE LENGTH OF DATE,TIME,TIMESTAMP ARE 4BYTES, 3BYTES,10BYTES RESPECTIVELY.

No idea what you are exactly asking for.

Thanks & Regards
Prabs