Re: Question posted to both Web400 & Midrange - db2_columns

FWiW for the subject being so non-descriptive, I had actually ignored the original post initially.

That the "new" version of the file that is created by CRTDUPOBJ is fully visible, I would infer the db2_columns is implemented via the SQLColumns() API and that the particular driver being used is implemented over the catalogs [versus inquiring the definition directly from the file object; i.e. per object-based].

A SELECT against the SYSCOLUMNS data for the "old" and the "new" files would show similar results to the output for the script if the error origin is the data in the catalogs. If the data is incorrect in the catalog, then the system requires a RCLSTG SELECT(*DBXREF) for recovery; DMPSYSOBJ QDBXREFQ* QSYS 0A issued prior to that reclaim request for recovery, would log some diagnostic details.

FWiW: Way back in the past there were a few defects which would be manifest as "missing" column details for some files. For other files it is completely valid that there is *no* column information; i.e. files which are not "externally described" are "program described", so the catalog can not know how any various program might want to describe the file. I query the QADBXREF and QADBIFLD files in QSYS instead of SYSCOLUMNS to verify the data because those files have a DBXREL [and DBIREL] field which indicates if the file is considered "relational"; DBXREL='N' indicates column information may correctly exclude the column detail in QADBIFLD.

Regards, Chuck

Cyndi Bradberry wrote:

I figured out part of my problem with the php script. The files
I was trying to access are too Old ! The script from "The IBM I
Programmer's Guide to PHP", page 246 simply retrieves the
library/file name and then lists the names of the columns
(fields).
<?php
//Set the database name
$tableName = 'FILENAME' ;
$libName = 'LIBRARY' ;
//Create the connection to the System i Relational Database
if (($dbh = db2_connect('SYSTEM','USERID','PASSWORD')) === false) {
echo 'connection failed.<br>' ;
echo db2_conn_errormsg().'<br>' ;
die() ;
}
//Retrieve a result set with the column info for the
//file specified at the top of the script.
if (($cols = db2_columns( $dbh, null, $libName, $tableName, '%' )) ===
FALSE) {
echo 'colums retrieval failed. <BR>' ;
echo db2_stmt_errormsg(). '<BR>' ;
die() ;
}
//Fetch the first row and output the file name
// and library name from the result set.
$column = db2_fetch_assoc($cols) ;
echo 'FileTable: ' ;
echo $column["TABLE_SCHEM"]."/".$column["TABLE_NAME"]."<BR>" ;
//Loop thru all the result set rows and list all the column names.
do {
echo $column["COLUMN_NAME"]."<BR>" ;
} while ($column = db2_fetch_assoc($cols)) ;
?>
Some files however, would not share their column information.
I wouldn't even get the name of the file or the library ! In
talking to another programmer, he said that some files could
not be accessed via ODBC. When
I tried the files he had problems with the same thing happened.

HOWEVER, if you copy the file to another library or even the same
library using a different name, it suddenly becomes visible to
the php script and to odbc. CPY and CRTDUPOBJ both seem to work,
not rgzpfm or chgpf. The files that are difficult are older files
on our system, generally created before 2000.

Is this something anyone else has come across ? Is there a PTF
I should be looking for ? We are on an 810 at V5R4.