At 02:05 26/07/2008, you wrote:

>> 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,

AFAIK, digits, spaces and commas are single-byte in UTF8. If you're using Fb 2 or higher, string overflows are determined at run-time. So I think you need to test these assumptions at least.

>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.

It depends on how many is "many", in context, of course. If this is a necessity to realise every data structure as an object in client memory at each connection, or worse, it's paragliding in Lead Boots.

> 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.

"Thousands of calls to the database" isn't the problem if the network architecture is appropriate. "Thousands of unnecessary packets across the wire" is a problem. The leanness of relational databases comes from retrieving no more data than is needed for the immediate task.

>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?

Can't answer that - firebird-net-provider list for .NET-related things, IBPP and its news forum if you need C++ wrappers.

./heLen