> 32K is too small?

That's what the app coders are telling me. Depending on the whether
they are passing in a Unicode string or not, and allowing for an
average size of 5 digits, that has room for 1000-5000 comma delimited
IDs. I would think that if that many IDs are being passed we have a
performance problem. In fact, I have repeated that enough times now
that they understand that you just don't make that many trips to the
database. To their credit, they've taken steps to remove thousands of
calls to the database.

But we're working with a custom, legacy ORM that was developed before
any of the current crop of ORMs existed. Ideally we would rework the
thing altogether, but as you know, entrenched, legacy systems like
this take time.

> On the client side you'll need a way to poke your string into a blob

(that's the challenge if you're using the raw API);

Right. That's one of the places I was getting stuck on. The app is
written in both C# and older C++, and I am leaning very much toward
using LINQ in C#. What's the alternative to raw API?

> on the server side, you'll need to write PSQL that parses the

contents of the blob. Since Fb 2 there's not much you can't parse in
a text blob; and 2.1 has a raft of internal functions implemented
that you could call on, without needing to bump into the limits (32K
varchar, 64K statement size including parameters, 48K for PSQL blr).

Thanks for the pointer. I just found your 2.1 release notes. (For
others reading:
http://www.firebirdsql.org/rlsnotes/Firebird-2.1-ReleaseNotes.pdf)

Looks like I have more reading to do...

Steve