| Subject | Re: [firebird-support] Blob External Filter |
|---|---|
| Author | Ann Harrison |
| Post date | 2003-09-10T15:09:27Z |
Regina Phandu wrote:
you access to the blob id (stored in the record) and the database handle
and the ability to call the API.
not be possible to write one in Delphi because the critical link back
into the engine has to be done with a call through a parameter.
request. That's not available through DSQL, so with any interface built
on DSQL, you need to use the blob API calls to get the translation you need.
very simple filter first - something exotic like up-casing all letters
as they go from the database to the output and down-casing them in the
other direction. Two advantages. First, it allows you to focus on the
mechanics - where the problem is - and not on what you're trying to do.
Second, it makes it possible for someone else to help debug.
Regards,
Ann
>Actually no, not quite. You can use any interface as long as it gives
>
>>From what I've understood from a presentation by Paul at the Fulda Firebird
>>Conference, BLOB filters are hard to write if you follow the docs - and,
>>even
>>worse, impossible to use if you don't use Embedded SQL.
>>
you access to the blob id (stored in the record) and the database handle
and the ability to call the API.
>>No - as you say below, they are written in Delphi, C++, or C. It may
>>
>
>Are there any examples of writing filters using Embedded SQL?
>
not be possible to write one in Delphi because the critical link back
into the engine has to be done with a call through a parameter.
>Right.
>In my understanding, external filters are defined according to the datatypes
>we plan to translate, and are written in either in C or Delphi and should be
>defined as a dynamic library, recognized by (defined against) the database.
>
>Thus, i can't see where Embedded SQL would fit in. Do you mean, that my appNo. Embedded SQL has the ability to pass blob subtypes as part of a
>should use Embedded SQL to support Blob data operations (insert, update,
>delete and select) ?
>
request. That's not available through DSQL, so with any interface built
on DSQL, you need to use the blob API calls to get the translation you need.
> Fortunately i have develop an abstraction layer (usingNot unlikely.
>APIs) to do those operations and it works fine for standard blob subtypes.
>Problem is, it doesn't work against non-standard (own-defined) subtype Blobs
>(sometimes even causing the server to crash !).
>
>My debugging have come toAt last check, they seem to me to be working. I'd suggest creating a
>the conclusion that the filters are not working the way they are supposed to.
>
very simple filter first - something exotic like up-casing all letters
as they go from the database to the output and down-casing them in the
other direction. Two advantages. First, it allows you to focus on the
mechanics - where the problem is - and not on what you're trying to do.
Second, it makes it possible for someone else to help debug.
Regards,
Ann