--- In firebird-support@yahoogroups.com, "Paul Mercea"
<paul.mercea@...> wrote:

>
> Thanks Helen an Adam for your response.
>
> SYS_LOCATION table have this definition:
> CREATE TABLE SYS_LOCATION (
> LOC_ID SHORTID NOT NULL /* SHORTID = INTEGER */,
> LOC_NAME NAME /* NAME = VARCHAR(30) */
> );
> Inserts:
> INSERT INTO SYS_LOCATION (LOC_ID, LOC_NAME) VALUES (1, 'Head Office');
>
> INSERT INTO SYS_LOCATION (LOC_ID, LOC_NAME) VALUES (2, 'Sale Point 1');
> INSERT INTO SYS_LOCATION (LOC_ID, LOC_NAME) VALUES (3, 'Sale Point 2');
> INSERT INTO SYS_LOCATION (LOC_ID, LOC_NAME) VALUES (4, 'WareHouse');
>
> I made this changes in proecdure:
> CREATE PROCEDURE T2 (
> T VARCHAR(50))
> RETURNS (
> IDN VARCHAR(50),
> IDL INTEGER)
> AS
> DECLARE VARIABLE STRSQL VARCHAR(200);
> begin
> strsql='select loc_id , loc_name from '||T;
> for execute statement strsql into :idl, :idn do
> begin
> suspend;
> end
>
> end^
>
> It's not working, but...If I chage strsql like Adam said:
> strsql='select loc_id , cast(loc_name as varchar(50)) from '||T;
>
> IT"S WORKING...
> Little strange, no???

varchar(30) <> varchar(50) (even though it a 30 fits into the 50)

The readme.execute_statement details the behaviour and it has the
following caution:

"To help (a little) with bugfixing, returned values are strictly
checked for correct datatype. This helps to avoid some errors where
unpredictable type-casting would otherwise cause exceptions in some
conditions but not in others."

Perhaps the rule could be relaxed a little in this situation, but it
isn't number one on my wishlist. Keep a closer eye on your data types
or it may bite you.

Adam