× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Wed, Apr 20, 2016 at 9:31 AM CRPence <crpbottle@xxxxxxxxx> wrote:

On 19-Apr-2016 06:12 -0500, Rob Berendt wrote:
An SQL TABLE is recorded as having the attribute 'TB', in the field
DBXATR of file QADBXREF of the System Database Cross-Reference [defined
with TEXT('PF-physical,LF-logical,TB-table,VW-view,IX-index')], and all
other non-SQL Physical Files are designated as having the attribute
'PF'. Thus both a non-described PF and a DDS-described PF appear as
'P', and a SQL-DDL-described TABLE PF appear as 'T', in the SYSTABLES
VIEW; each one-character value designation, being derived from the
expression SUBSTR(DBXATR, 1, 1) that defines the TABLE_TYPE FOR TYPE
column of that SQL catalog VIEW.


I've noticed the P versus T thing looking at qsys2.systables, and its nice
to know the internal metadata that that gets derived from. That being said,
is there any practical difference? Can I not add as second member to TB or
execute an ALTER TABLE on a PF? It seems like that differentiation in the
meta data is mostly forensic.

Justin

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.