RE: SQL Functions

This is where a PODBS (plain old database server) program really starts
to make sense.  The fact that each UDF has to execute its own SELECT
statement is just asking for trouble long term.

Instead, write a server program that reads the records and performs the
appropriate manipulations.  Calls this server and retrieve one record at
a time from it.  Getting the data can be done many ways; one option is
to have the server return a data structure containing the normal record,
and a second one containing the computed fields.

If you need SQL selection capabilities, then pass in the selection
criteria and use embedded SQL to select the records.

Joe

> From: Elvis Budimlic
> 
> >From: Dave Smith
> >Select
> >            ItemDescription(ITEM#) as "Item Description",
> >ItemQOH(ITEM#) as "Quantity on Hand",
> >Item12MonthUsage(ITEM#) as "Average Yearly Usage"
> >From
> >            SomeListOfItems
> 
> >Does each one of these functions need to retrieve this information
from
> >ITEMMSTR or does the record somehow stay resident in memory from one
> >function request to the next.
> I'm pretty sure input record is the same for all three UDF
invocations.
> 
> >So when I roll this out to 500 users is
> >the system going to get slammed?
>
> It depends on how complex your functions are.
> Rule of thumb I use with my UDFs is to make them as simple as possible
> (single purpose functions).
> If your UDFs are rather simple (i.e. add these two numbers and return
the
> sum, convert decimal to date), there shouldn't be much overhead.
> If each function runs another SQL statement in turn and the FROM file
has
> lots of records, I can see lots of 'slamming' going on.