Re: Debugging an SQL Function

eftimios pantzopoulos wrote:

I’ll draw this to a close, but what are the rules for posting
when a topic takes a different path from the original subject
line?

Although a moderated forum, there is no /rule/ as such. It is IMO just a courtesy to make the discussion match the subject; not just for those who might choose to follow the current thread, but even more importantly for searching the archives. Why frustrate searchers who might find the /subject thread/, but end up reading messages that have unrelated discussion?

I had a vague feeling that an SQL function which is implemented
through another language was just a shell, but thought that there
might still be some C code to implement the interface which could
be stepped through.

No additional code is available to the SQL programmer for the interface. It is the DB2 for i SQL runtime [as part of the OS] which implements the interface to the external program, based on what is defined by the CREATE FUNCTION both to pass as parameters and to receive as a return value from the program named on the EXTERNAL NAME.

I guess the process of registering the function must check that
the parameters and return values are all in alignment in terms of
position, type and size?

Between what is defined by the CREATE FUNCTION and the existing External [service] program at definition\create time? That is actually the responsibility of the programmer of the external program and the creator of the function. The external program need not even exist; i.e. in that case there would be no possibility to validate the parameter\return-value interface. I suppose with PCML such validation could potentially occur, but AFaIK there is nothing but what the programmers have done to ensure the compatibility between the two. That is, the program is created with the parameters to match the PARAMETER STYLE that was specified on the CREATE FUNCTION, and any errors would occur at the runtime.

And that invoking the SQL function simply passes the parameters
through whatever parameter style has been declared.

Correct.

So in essence, it’s either all de-buggable or not at all depending on the language being SQL or not?

Not sure what is meant by that. The programs that implement the FUNCTION are debug capable whenever they are compiled as such.

There is no more capability to debug the interface between the SQL function and the external program, than there to debug that interface for the service program as SQL FUNCTION. The interface is still the SQL run-time, not available to be debugged except by the IBM development. The only difference being, that the SQL function is generated source, parameters and all, such that an interface mismatch would be a defect with the DB2 for i SQL versus a programmer error for having mismatched the PARAMETER STYLE and the external program parameter definitions.

<<SNIP>>

Regards, Chuck