Subject Re: Using BLOB SUB_TYPE 1 as parameter
Author Roman Rokytskyy
Helen,

Some info I forgot to include in my previous post. I'm using Firebird
1.0 build 794.

> You can't do a blob-to-blob comparison directly - you need a UDF.
>
> You can do:
> SELECT blob_field FROM test_table WHERE blob_field CONTAINING ?
>
> as long as you pass a string to the parameter.

Yes, this works. But it is not strict "=" comparison, is it?

> And you say that this works too?
> SELECT blob_field FROM test_table WHERE blob_field = 'abc'
>
> If so, that's good. Claudio added the capability to cast a string
> to a text blob transparently, a long time ago.

Yes, I have tested it.

> The problem with this one:
> SELECT blob_field FROM test_table WHERE blob_field = ?
>
> may be that the API doesn't know the type of the parameter,

No, it knows the type of parameter to be SQL_BLOB. As you could see
from the algorithm presented in previous message statement is prepared
and executed without problem. It fails in isc_dsql_fetch.

So, if blobs cannot be compared with "=" sign, I think we should
disable preparing of such statements. I will test it with FB 1.5 to
check if problem still exists.

> whereas
> presenting the literal string provides this information explicitly.
> Could
> you try this:
>
> SELECT blob_field FROM test_table WHERE blob_field = cast (? as
> Varchar(80))

Here I get

Dynamic SQL Error
SQL error code = -804
Data type unknown

Following is not related to this problem, but same error message
happens when trying to execute following statement (also reported in
FB-Java)

SELECT * FROM users WHERE passwd_digest = md5(?)

and

DECLARE EXTERNAL FUNCTION MD5
CSTRING(255),
CSTRING(32)
RETURNS PARAMETER 2
ENTRY_POINT 'StringToMD5String' MODULE_NAME 'md5udf'

I found a closed entry in bug tracker, but problem exists in FB 1.0
and FB 1.0.2 at least for the specified UDF and some other statements
(like SELECT ? FROM rdb$database or SELECT 1 FROM rdb$database WHERE ?
= ?).

Best regards,
Roman Rokytskyy