Hi Tobias,

> Hello again,
>
> the problem is that to optimize my stored procedure, I need a way to
> store about 1000 temporary numbers in an array. I want to store them in
> memory, not in the database. So I thought I'd have to use a higher level
> language than the stored procedure language.
>
> Martin:
> > Should you do it? NO!
> > UDFs aren't supposed to be long and time consuming
> > tasks - let alone creating database connections!
>
> I'm not quite sure. Currently, my stored procedure takes
> a long time to finish. Does it really make a difference
> whether this time is spent in the stored procedure or
> within the UDF? On Windows, that is?

The more complex the UDFs, the harder it is to get them
thread-safe too :)

> About the database connections - I could move those into
> a separate program that runs on the server. The UDF would
> communicate with that software but not make database
> connections itself. The UDF would then have to wait until
> the other software is done.

Do note that if your data is inside some kind of transaction,
you will not be able to read it from the other application.

> Alternatively, the UDF could return immediately. The additional
> program on the server would set a flag when it's done. Applications
> running on the client would have to watch this flag.

That would be better I guess - but why use an UDF for this instead
of "simple" events??


With regards,

Martijn Tonies
InterBase Workbench - the developer tool for InterBase
http://www.upscene.com

Firebird Workbench - the developer tool for Firebird
http://www.upscene.com

Upscene Productions
http://www.upscene.com

"This is an object-oriented system.
If we change anything, the users object."