Re: Use of the SQLDA - Example for SQL DESCRIBE TABLE

[CRPence <CRPbottle@xxxxxxxxx>]

  I found an old file that contained the following expression 
[since updated with BIN types & reformatted; hopefully no errors]. 
I had used that expression to successfully generate most 
non-IDENTITY, non-UDT, non-LOB, non-DL, & non-FLOAT [and VARxxx 
without ALLOCATE] column definition DDL string.  Some of the latter 
types may function although I never had any need for them; they 
remained untested.

 select
   column_name concat
   case when sys_cname <> column_name
        then ' FOR ' concat sys_cname concat ' '
        else ' ' end concat
   case data_type
        when 'TIMESTMP' then 'TIMESTAMP'
        when 'VARG' then 'VARGRAPHIC'
        when 'VARBIN' then 'VARBINARY'
        else data_type end concat
   case when data_type in ('SMALLINT', 'INTEGER', 'BIGINT')
        then ''
        when datetime_precision is not null then ''
        when data_type = 'FLOAT'
        then '(' concat precision concat ') '
        when data_type = 'ROWID' then ''
        when scale is not null and precision is not null
        then '(' concat precision concat ', '
                concat scale concat ')'
        else '(' concat length concat ') ' end concat
   case when ccsid is not null and data_type not in
          ('BLOB','VARBINARY','BINARY','ROWID')
        then ' CCSID ' concat ccsid
        else '' end concat
   case nulls when 'N' then ' NOT NULL'
        else '' end concat
   case default when 'Y'
        then ' WITH DEFAULT ' concat ifnull(dftvalue, '')
        else '' end
 from qsys2/syscolumns S
 where sys_dname = 'QSYS2' and sys_tname = 'SYSROUTINE'

  Note that DATALINK still does not have the CCSID in [which 
appears to be a defect with] the catalog VIEW SYSCOLUMNS [and its 
underlying file QADBIFLD] that has still never been reported and\or 
corrected.

  Having offered that, I suppose the Generate SQL Data Definition 
Language source QSQGNDDL API could be used to generate the column 
definition.  Afterwards, the source would be parsed for the column 
name of interest.  IIRC the column_name always starts on a new line, 
and the prior non-blank character is either the left parenthesis or 
a comma [the former for the first field, and the latter for other 
fields].
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/apis/qsqgnddl.htm

Regards, Chuck

Pete Helgren wrote:
> Luis Rodriguez wrote:
> > Wouldn't the use of the SYSCOLUMNS view work for you? IIRC. it 
> > should have all the info you need...
> Yes, I had looked at that and maybe I dismissed it too quickly. 
> The trick would be to grab the correct information so that I can 
> determine, correctly, all the attributes of the column I want to 
> duplicate. This syntax looks close:
>
> SELECT
>   DATA_TYPE, LENGTH, NUMERIC_SCALE, IS_NULLABLE  , HAS_DEFAULT
>  FROM syscolumns
>  WHERE table_name = #{table_name}
>    and column_name = #{column_name}
>
> I'd have to evaluate the data_type to figure out which of the 
> remaining variables would apply. Identity columns are 
> particularly a challenge. Once that was done, I'd still have to 
> construct the alter table statement to add the column. Tricky, 
> but not impossible.
>
> <<SNIP>>
>
> If I could create a stored procedure that was only in SQL, that 
> would be more portable since I could ship a CREATE PROCEDURE 
> statement that would generate the procedure without needing to 
> also restore RPG source and compile or need a save file with the 
> RPG object in it. So SQL would be cleaner. I just can't figure 
> out how to do everything in SQL so I may just have to bite the 
> bullet and write it all in RPG.