> Unfortunately, I don't touch the sql string. If you had written
> it
> insert into t (k, blobfield) value (1, ?)
>
> and assigned "hello, world" to the parameter, it would work fine.

This is the typical case, but not always possible or desirable, I would
have to conduct a poll to see why several people ask for the same ability.

> In my new enlighted persona, a blob is a storage mechanism, not a
> data type, and appropriate conversions are automatic and invisible.

Tell this to the developers if you make them believe class CLOB surrounds
large varchars but they cannot insert a literal string.
:-)
Sincerely, I think this is one of the automatic conversions that can be
done in the future.

> But here a question for you and the other InterArchies: If in the
> above example you assign the int32 to the parameter what should
> show up in the blob? And if the problem with a de facto clob,
> would the answer be different.

Gosh! Tree days without connecting and now I'm swimming in tons of emails
and newsgroup articles!
If I understand well, you're asking about inserting an arbitrary integer
value, right? In this case, in a blob field, I would expect the value to be
stored in binary like blr for example. If I want the textual representation,
I would convert the value to a string representation before feeding the
argument.
Historically, IB's BLOBs (sorry, I meant blobs) don't exhibit any
difference regardless of their underlying sub_types. Even more, regardless
of the proposed types that are in ibapi.h (0 for binary, 1 to 8 for internal
use and... 20 to 30 for Dbase&Paradox... argh), I don't see any any
difference in the storage representation, at least between types 0, 1 and
the negative values left to user types.
Until now, IB seems to behave 99% neutral respect to sub_types, except for
some built-in blob filter that operates I forgot where.
I don't know if you're asking only for the JDBC/ODBC implementation or for
the engine itself. Regarding the engine, if you do some different
interpretation of the text sub_type, maybe some applications will be in
trouble, although when one defined a text blob, it's assumed to keep
strings. Regarding the ODBC driver, the CLOB class could ensure it's
targeting a text blob and so on, store any parameter in its string
representation. Now if you follow in this trend, we could discuss if such
field should have a blob filter to understand collations when values are
stored and retrieved (not for ordering, of course) or should continue
behaving as charset/collation neutral.
Since I understand the engine doesn't worry too much about 0 or 1 as
sub_type and that interpretation is left to higher layers, I think the clob
class could be a way to make text blobs appears as large varchars... with
limitations, of course (order by, etc.).
One interesting thing is what do you do with formatted text. For me, if the
formatting is text itself like RTF, it could be stored in a text blob.
Otherwise, if it's binary like DOC format, the distintion blurs, because
probably some UI control will expect this info kept in a memo-like field
(namely, text blob) even if the internal format keeps non-readable
characters.

> Your replies should be well thought out and carefully worded. You
> may start writing.
> Jim Starkey

Since I'm too far from you and you aren't my boss, I can write with virtual
impunity.
;-)

C.