Hi,

> MT> ? I don't get this completely... You mean he's trying to use the UDF

without

> MT> your app? So he is also accessing the database without your app? If

so,

> MT> why bother?
>
> I'll tell you.
> That UDF relies on filling a memory cache with values from the database;
> if the cache isn't filled one can't use the UDF reliably, so I have raised
> an exception to cater for the (unlikely) case.
>
> My client applications will all call a SP on connect that fills that
> memory cache, so whatever you do in those applications the UDF will
> work reliably. I am trying to cover the case in which someone accesses
> the database and calls the UDF without first calling the SP that fills
> the cache. Heck, I *do* have it covered, just wanted to raise a less
> obscure error.

I still think this is the best you can do ... Delphi Exceptions are a
typical
Delphi thing and shouldn't be allowed to "escape" a DLL - the calling
application doesn't know how to handle them. Even if it's a Delphi
application
that's calling your DLL... That's why all Windows stuff uses error codes...

Perhaps you can control the output to be really really obviously wrong
instead of raising the error...


With regards,

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

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