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

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.