At 05:54 AM 28/01/2008, you wrote:

>the following sp causes the same error.
>"..is not a valid floating point value" in debug mode.

Some forensics:

This isn't a Firebird error, it's a Delphi one, coming either from your application or from a custom UDF written in Delphi. It is telling you that some function or procedure in the Delphi code was expecting a floating point argument but got an "empty string" character (ascii 0) instead.

-- Firebird doesn't have a "debug mode" so I'm guessing DBW or IBExpert, both of which are written in Delphi.

-- How was the procedure invoked in the debugger? did you, for example, try to invoke it using SELECT instead of EXECUTE PROCEDURE?

-- on the UDF front, if you are using the STRLEN function from ib_udf, it's written in C, so the error isn't coming from there.

The "shipped" declaration of STRLEN is as follows:

DECLARE EXTERNAL FUNCTION strlen
CSTRING(32767)
RETURNS INTEGER BY VALUE
ENTRY_POINT 'IB_UDF_strlen' MODULE_NAME 'ib_udf';

Now, you can make multiple declarations of a UDF, e.g.

DECLARE EXTERNAL FUNCTION strlen
CSTRING(255)
RETURNS INTEGER BY VALUE
ENTRY_POINT 'IB_UDF_strlen' MODULE_NAME 'ib_udf';

DECLARE EXTERNAL FUNCTION strlen_longest
CSTRING(32767)
RETURNS INTEGER BY VALUE
ENTRY_POINT 'IB_UDF_strlen' MODULE_NAME 'ib_udf';

So, if you inherited the database from someone else, check the declarations *in the database* to verify that the argument is what you assume.

>CREATE PROCEDURE P_TESTCONCAT
>AS
>DECLARE VARIABLE TXT VARCHAR(2000) DEFAULT '';
>DECLARE VARIABLE CTX VARCHAR(13) DEFAULT ' BEZEICHNER: ';
>DECLARE VARIABLE NUM INTEGER DEFAULT 12345678; /* THIS IS A VALID
>NUMBER, INTEGERS CAN STORE UP TO 2,147,483,647 */
>DECLARE VARIABLE LEN INTEGER;
>
>BEGIN
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
> /* THE NEXT COMMAND CAUSES THE ERROR, THE LENGTH OF THE RESULT
>EXCEEDS 255 CHARACTERS */
> TXT = TXT || CTX || CAST(NUM AS VARCHAR(8)); LEN = STRLEN(TXT);
>END

Exactly which error happens at this point? by "exactly" I mean all text and codes that are returned. It's impossible to nail this with vague observations.

-- If your utility tool actually allowed the SP to be defined then try a more revealing test:

Commit all the transactions the tool currently has running and shut down the tool.

Then go to the command line and invoke your testing statement in isql. Whatever error comes back then will be a Firebird error.

If you want to test the length of the string step by step then write your procedure as demonstrated by Set. The way you have written the procedure, you have no way to tell at what point it is falling over.

./heLen