Subject | Re: [firebird-support] Problem when restoreing |
---|---|
Author | Helen Borrie |
Post date | 2005-08-10T00:40:59Z |
At 08:15 AM 10/08/2005 +1000, you wrote:
any data you assign to it must have matching attributes. Inside the PSQL
module, the return argument is a variable that has to obey the rules.
By defining this:
returns (
RESULT_STR VarChar(150) CHARACTER SET ASCII)
you restrict all strings applied to the variable to being 150 bytes long
and in the ASCII character set. If the strings you assemble in your code
are in some other character set, then you'll have to use a CAST to have the
engine convert them.
Depending on the version of Firebird you are using, you might well be
bumping into a bug that appeared somewhere during Fb 1.5.x development,
where the character set and collation attributes of data being read from
tables gets lost in PSQL. If that's behind your problem, it is fixed in
the forthcoming v.1.5.3 release. Until then, it's possible you'll need to
cast the *read* data, even if it is stored in columns that are defined as
character set ascii.
./heLen
>Good morning all,Simply enough, if you define a variable that has certain attributes, then
>
>We had the following error reported with one of our DB's. Helen was kind
>enough to give us a possible solution to the problem.
>
>We would now like to no "Why" the error occured so that we do not repeat
>the problem next time.
>
>Could anyone explain the why bit to us.
any data you assign to it must have matching attributes. Inside the PSQL
module, the return argument is a variable that has to obey the rules.
By defining this:
returns (
RESULT_STR VarChar(150) CHARACTER SET ASCII)
you restrict all strings applied to the variable to being 150 bytes long
and in the ASCII character set. If the strings you assemble in your code
are in some other character set, then you'll have to use a CAST to have the
engine convert them.
Depending on the version of Firebird you are using, you might well be
bumping into a bug that appeared somewhere during Fb 1.5.x development,
where the character set and collation attributes of data being read from
tables gets lost in PSQL. If that's behind your problem, it is fixed in
the forthcoming v.1.5.3 release. Until then, it's possible you'll need to
cast the *read* data, even if it is stored in columns that are defined as
character set ascii.
./heLen