[snip]

>>> I have just had another parameter problem with a straight
>> forward TIB_Cursor
>>> with 'and((:WHS='')or(WHS=:WHS))'. When the value of
>> Parameter WHS is set
>>> to '', IBO chooses to convert that to ' ' (WHS is char(1)),
>> this then
>>> causes a string truncation error.
>>>
>>> IMO parameter handling could be improved.
>>>
>> No! That would break lots of applications. (Strange though
>> that you get a string truncation error, should be just an
>> empty result).
>
> I havent thought through what the changes might be but Im not convinced they
> would have to break applications.
>
>> I use a similar construct a lot. It caters for a generic
>> application and lots of reporting queries. Try to write;
>>
>> and ((:WHS = ' ') or (WHS = :WHS))
>>
>
> Sure I could. Then in Delphi I would have
> if eWHS.Text='' then
> paramByName('WHS').AsString:=' ' else
> paramByName('WHS').AsString:=eWHS.Text;
> As opposed to just
> paramByName('WHS').AsString:=eWHS.Text;
>

Yes, of course. eWHS is a Delphi string. :WHS is a FB SQL parameter.
Assuming they work the same way is... Man, there's a whole *industry*
out there making money out of trying to make an OO language and an SQL
API work seamlessly. In Pascal, in Java, in C# and C and C++ and
whatever. Ever other week I read about a new company starting with lots
of risk capital that claims it has the final solution... OK, off topic.
Lets get back:

[snip]

>
> This is a simple stored procedure
>
> CREATE PROCEDURE TEMPTEST(
> WHS CHAR(1))
> RETURNS (
> DESCRIPTION VARCHAR(15))
> AS
> begin
> for select description from warehouses
> where ((''=:WHS)or(ref=:WHS))
> into :description do suspend;
> end
>
> It works perfectly if you send it an empty string (ie it returns all
> warehouses rows). Also this isnt a client interface thing when setting the
> paramater value - if you add the line WHS=''; (overriding the input value)
> it still works. So if FB is happy to handle an empty char parameter I don't
> see why IBO shouldn't be.
>

I would [guess] that :WHS in the above example can be called a parameter
before you execute the SP. Once inside it's a variable. The SP/Trigger
language (PSQL, ?) can handle stuff that the query engine (DSQL, ?) can
not. Lot's of stuff.

Anyway. The Delphi or C++ string class is not the same as passing
parameters to an SQL Query.

But back to your original "complaint". You are suggesting that IBO
should trim parameters. This is IMHO wrong. If it did then my statements
would stop working. IBO already has lots of options to tell it how to
handle field values and parameter values. I guess you could make IBO do
something in this regard that the other interfacing components would not.

Regards,

/Dany