RE: SQL question on default *LIBL at connection

Nice find Chuck. Jim is using a .NET provider (IBM.Data.DB2.iSeries), not
the OLE DB one. Do you know if same restrictions apply to the .NET driver?

Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: Re: SQL question on default *LIBL at connection

The SQL function resolution is not the same as locating a program
in a dynamic call. First, it uses the SQL PATH, not simply *LIBL.
Second, there is /overloading/ for routines. Third, it is not just
/resolve system pointer/ MI instruction, but /routine resolution/
code which references the data in SYSROUTINE in QSYS2. Then because
overloading is possible, a /best fit/ may be required. Thus as I
understand, if the first of multiple matches for the name is not an
exact match [for parameters], resolution must defer to /best fit/.
If there is a UDT, then the type must be explicitly cast, else the
use may be ambiguous. Additionally DeriveParameters() will not work
for overloaded stored procedures according to [.pdf on web]:

Table 37. IBM OLE DB .NET Data Provider restrictions
:Class or feature : OleDbCommandBuilder.DeriveParameters
:Affected DB2 : All
:Restriction description : method will fail for overloaded stored
procedures... multiple stored procedures of the name "MYPROC"...
method will retrieve all of the parameters for all overloaded SP.

Regards, Chuck