>----- Original Message -----
>From: "sllimr7139" <rmcontrols@...>
>To: <IBObjects@yahoogroups.com>
>Sent: Wednesday, October 22, 2003 8:06 AM
>Subject: [IBO] Creating UDFs with IBO.
>
>
> > Is it possible, is there some example delphi code available?
> >
> > I've done the usual searches and came up empty. Any
> > help would be appreciated.
> >
> > I'm trying to come up with a UDF that can manipulate blobs
> > and preferably a generic solution common to Delphi/Kylix and IBO.
> >
> > Ryan.

Strange, I didn't get the original posting.

My suggestion is that you take a look at the source code for Greg Deatz's
FreeUDFLib, as he already has blob-manipulation UDFs there, including one
for converting a blob to a string. Greg has already done the Delphi
spade-work.

You don't need IBO, BDE or any other data interface to create UDFs, since a
UDF should never be used to connect to databases. UDFs are functions to
manipulate constants - an adjunct to the internally-provided functions.
They take a discrete item of data as an input and return a discrete item as
output.

FreeUDFLib has been partly translated to Linux/Unix, as I understand, but
not using Kylix. Someone (possibly Rob Schieck) did it in C or C++ back in
2000. There is some C source at the ibphoenix site that doesn't have a
great reputation for robustness, though I haven't tried compling it
myself. I expect there might be more recent sources at CodeCentral.

I recently bought Kylix 3 Pro with the aim (one of several) of doing a
Kylix version of FreeUDFLib---after the book is finished! If you have
Kylix, you could try updating and compiling Greg's Delphi code, using the
Delphi kit from IBP. I last compiled it without modification on Delphi 5.

I don't altogether agree with Jason's philosophy on UDFs. There are some
things we do want to do on the server to ensure consistency, rather than
hand over to client applications to be done in n different ways. We don't
all have the luxury of being in command of all client accesses to our
databases.

But UDFs are a double-edged sword - they allow us unlimited ability to
extend server functions but the cost is disaster if implementation isn't
completely atomic, careful and thoroughly tested. Using them to connect
back into the database, or to another database, or to trigger off a
separate process somewhere else on the system, is a complete no-no.

Helen