Hi David,
Thank you for your enquiry.
By definition, LMi manages objects with or without source.
In most cases, each object may be managed with its source as a pair. (One source generates one object)
SQL objects are non-source based and may be managed with their specific pseudo source.
In your example, you have two distinct objects.
FUNCTION DATE_TO_USA_NUM
FUNCTION DATE_TO_ISO_NUM
Hence I would expect two distinct functions (*FUNCTN) to be defined and managed in LMi. Each function may have its distinct pseudo source or as no-source.
Of course, you could manage an object of type *SRCMBR which could contain a number of SQL objects. However, this source member cannot be linked to a specific LMi object since one object is paired with its own source. The *SRCMBR may be executed outside of LMi to generate multiple objects where each object could be managed in LMi as non-source object. This approach is not recommended since *SRCMBR would have to be checked out / edited for each object being changed possibly by different developers.
Please let us know if you have further questions on this topic.
Best regards
------------------------------
Jay Mikaiel
Senior Technical Support Engineer
Rocket Software
UK
------------------------------
Original Message:
Sent: 08-16-2022 15:09
From: David Taylor
Subject: SQL-defined UDF Question
I wanted to define this UDF as all SQL to make it easier to use with external platforms like SSRS. Is there a hard limit of one SQL UDF per source member? See attached. When I did the single, it worked and CREATE passed. When I tried various ways to code more than one UDF in the same source member, it failed every time. I await the wisdom from my companions on the journey.
------------------------------
David Taylor
Senior Developer
Range Resources Corporation
Fort Worth TX US
------------------------------