Re: SQL Field Defintions

Alan,

You forgot a fifth option:
5) If you want to get the definitions of the columns in the result set use
descriptor SQLDA. This DS can returns the number of columns in a result
set, the data definitions of each column in the result set, as wel as the
actual data of a FETCH operation. As Scott has pointed out: the programme
(host) variables to retrieve the data into do not have to be the exact
length of the data retrieved: you can fatch a 7P0 numeric data in a 30P9
variable. Perhaps ugly to use, but you can use it on all SQL statements.

Regards,
Carel Teijgeler
 
*********** REPLY SEPARATOR  ***********

On 25-9-2006 at 17:23 Alan Campin wrote:

I brought this up on a previous post about doing data structures to be

used with a SQL Select statement. 

If I have something like this:

d dsMODATA.                  ds                  Qualified
d   CITEM.                               15a
d   CITWH                                 3a
d   ACSTD                               15p2

Has anybody come up with a good way to deal with this? It seems like I

have four choices in dealing with this.

1. Lookup the field type and size in the MODATA file and hardcode. Ugly.
2. Define the file in the F specs but never open. Reference the field from

the dummy file. Real Ugly.

3. Define a qualified external data structure for MODATA and base it on a

pointer so it takes no storage. Reference the fields from the

qualified data structure. Not as ugly but fills up compile listing with a

ton of junk.

4. Define am empty table for each data structure and reference as external

data structure. Really ugly.  

Anybody come up with a better way of doing this and no I don't want to use

select * from?