At 07:20 PM 3/04/2009, you wrote:

>I tried to post it to newsgroup, but it didn't arrive, so I'm posting it
> to mailing list also.
>
>Table ZZZ has VARCHAR(6) field XXX
>
>Following query works without errors:
>
>"SELECT * FROM ZZZ WHERE XXX LIKE '001001%'"
>
>But following query does not:
>"SELECT * FROM ZZZ WHERE XXX LIKE :XXX"
>where parameter :XXX is set to '001001%'
>
>The error is:
>Dynamic SQL Error
>SQL Error Code = -303
>arithmetic exception, numeric overflow, or string truncation.
>
> I understand, that it is caused by the fact, that parameter is longer
>then field name, but is this correct behavior?

Wow, that's a strange guess! A "named parameter" is a purely Delphi thing.

>And why is it behaving
>differently, when string is embedded in SQL instead of passing it as
>parameter?

A parameter is not a variable: it is a placeholder for a data element of a known type. The statement

SELECT * FROM ZZZ WHERE XXX LIKE :XXX
is passed across the API as
SELECT * FROM ZZZ WHERE XXX LIKE ?

The XSQLVAR structure has been primed to expect a string of no more than 6 characters (that's what VARCHAR(6) prescribes) but you are passing 7.

Make the parameterised statement as

SELECT * FROM ZZZ WHERE XXX LIKE :XXX || '%'

and pass only the value for the parameter itself.

If all of these varchar(6) values are 6 characters long then you don't want to use the LIKE predicate, anyway. It's an equality check you want for this. If in fact you have some values that are shorter than 6 characters, use STARTING WITH instead and avoid the problems of having to mess about with Delphi strings:

SELECT * FROM ZZZ WHERE XXX STARTING WITH :XXX

./heLen