× 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.



I suspect you are right in that my diagnosis and symptoms are very likely wrong. If I knew what I was doing I would probably be able to fix it. I will say though that upper casing and changing the period to a slash did cause two other errors to disappear.

On 10/8/2015 4:36 PM, CRPence wrote:
On 08-Oct-2015 15:31 -0600, Booth Martin wrote:
On 10/8/2015 11:02 AM, Dave Boettcher wrote:
I'm trying this out in interactive SQL and can't seem to find the
qsys2/users table. <<SNIP>>

I had to UPPERCASE "qsys2/users" for it to be found.


Had to upper-case the undelimited "qsys2/users"? That is, is the
claim made above, that QSYS2/USERS had to be specified instead of
qsys2/users being specified? Perhaps no matter, per seemingly something
is amiss with that claim. Seeing what was the failing request [and the
error details] and what was the successful request, likely would expose
a difference beyond the casing.

FWiW:

Undelimited identifiers in SQL are automatically folded to upper
case, just like the CL command-line operates. None of the [presumably
functional] offers of examples for the proper invocation included
upper-case names, so whatever was the origin for any "not found" error,
apparently the issue was not due to upper vs lower vs mixed case.

If delimited names [aka identifiers], then "QSYS2" and "USERS", with
the appropriate [specific to the NAMING OPTION] qualifier-character;
e.g. the slash. The specification "QSYS2"/"USERS" is no different than
specifying Qsys2/Users because the latter is implicitly folded to
upper-case and for the former the double-quote as delimiters are
superfluous [thus in essence, the double-quotes are stripped], but the
specification of "Qsys2"/"Users" is different from specifying
"qsys2"/"users" because the double-quote as delimiter dictates no
folding of the names. Since some revision level [TR, PTF, ??], on V7
[IBM i 7.#], the ability exists to use the period as qualifier-character
irrespective the chosen SQL naming-option; in some earlier releases, in
my experience, scalar functions could not even be library-qualified when
using System [*SYS] naming, so they were limited to being found
according to the PATH.

As other replies have offered, what was referenced by qualified name
is not a TABLE or a VIEW, but a User Defined Table Function (UDTF). As
a User Defined Function (UDF) [table-function or scalar-function], the
name must be followed by parentheses [to distinguish the identifier as a
function vs a column-name or a variable-name], and any required
comma-separated arguments specified betwixt the left-paren and
right-paren characters. The function will be found when correctly
specified with both a compatible number of arguments and a compatible
data-type for each argument, irrespective the casing of non-delimited
names; in the given example, apparently zero-arguments is at least one
supported invocation. I do not know [nor really care much] why the SQL
insists the table-function reference be enclosed in a TABLE() for a
table-reference, instead of just intuiting the intent, I just appease
the picky language.


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.