Im getting the following error when using FireDAC and Firebird 1.5

Query: SELECT RDB$TRIGGER_NAME FROM RDB$TRIGGERS 
Error: [FireDAC][DatS]-32. Variable length column [RDB$TRIGGER_NAME] overflow. Value length - [13], column maximum length - [10]

I think its got to do with the character set and tried various settings but cant get it to work.

Im using Delphi XE5.

Edited by: Willem Louw on Jun 5, 2014 4:23 AM

> Query: SELECT RDB$TRIGGER_NAME FROM RDB$TRIGGERS 
> Error: [FireDAC][DatS]-32. Variable length column [RDB$TRIGGER_NAME] overflow. Value length - [13], column maximum length - [10]

This issue seems to be fixed in FireDAC XE6.

-- 
With best regards,
Dmitry Arefiev / FireDAC Architect

> {quote:title=Dmitry Arefiev wrote:}{quote}
> > Query: SELECT RDB$TRIGGER_NAME FROM RDB$TRIGGERS 
> > Error: [FireDAC][DatS]-32. Variable length column [RDB$TRIGGER_NAME] overflow. Value length - [13], column maximum length - [10]
> 
> This issue seems to be fixed in FireDAC XE6.
> 
> -- 
> With best regards,
> Dmitry Arefiev / FireDAC Architect

I upgraded to XE6, but it is still not working. 
It is a week later. Im minus $700. And Im a week behind. 

I think this could solve the problem :
FireDAC.Phys.IBBase.pas Line 2074

        if (IBConnection.FEnv.Lib.Brand = ibFirebird) and
 +        ((ASQLDataType <> SQL_VARYING) and (ASQLDataType <> SQL_TEXT)) then
          ALen := ASQLLen div IBConnection.FEnv.Lib.GetBytesPerChar(ASQLSubType)
        else
          ALen := ASQLLen;

Same as with the change @ line 2459 that was done in the latest version.
Except leave the length as is and not div it by "GetBytesPerChar"

Edited by: Willem Louw on Jun 13, 2014 6:52 AM

> {quote:title=Jeff Overcash (TeamB) wrote:}{quote}
> Willem Louw wrote:
> >> {quote:title=Dmitry Arefiev wrote:}{quote}
> >>> Query: SELECT RDB$TRIGGER_NAME FROM RDB$TRIGGERS 
> >>> Error: [FireDAC][DatS]-32. Variable length column [RDB$TRIGGER_NAME] overflow. Value length - [13], column maximum length - [10]
> >> This issue seems to be fixed in FireDAC XE6.
> >>
> >> -- 
> >> With best regards,
> >> Dmitry Arefiev / FireDAC Architect
> > 
> > I upgraded to XE6, but it is still not working. 
> > It is a week later. Im minus $700. And Im a week behind. 
> > 
> > I think this could solve the problem :
> > FireDAC.Phys.IBBase.pas Line 2074
> > 
> >         if (IBConnection.FEnv.Lib.Brand = ibFirebird) and
> >  +        ((ASQLDataType <> SQL_VARYING) and (ASQLDataType <> SQL_TEXT)) then
> >           ALen := ASQLLen div IBConnection.FEnv.Lib.GetBytesPerChar(ASQLSubType)
> >         else
> >           ALen := ASQLLen;
> > 
> > Same as with the change @ line 2459 that was done in the latest version.
> > Except leave the length as is and not div it by "GetBytesPerChar"
> > 
> > Edited by: Willem Louw on Jun 13, 2014 6:52 AM
> 
> No, if you look at the case statement it is only going into that section if it 
> is one of those two types (SQL_NULL being the third but meta data columns are 
> not going to be that type).
> 
> The problem, if FB is still like InterBase in 1.5 since this predates IB 6.0 
> which FB was based upon, is that the RDB$TRIGGERS (actually all the system 
> tables) are declared as UNICODE_FSS character set for character data, which 
> means it has a Bytes per character of 3, but the reality is the data is ANSI so 
> the length being sent across of 32 is being divided by 3 because the server is 
> saying that is how it is, but the reality is it isn't (hence the 10 length in 
> the error).  This is true only for character data in the system tables, all user 
> tables are the correct length for the bytes per character on of the underlying 
> character set defined for that column.
> 
> What I had to do with IBX was to check when the relation name started with RDB$ 
> and the sqlLen mod 3 wasn't 0 then the sqllen is 1 otherwise it is 3 for that 
> SQLSubtype.  I suspect something similar needs to be done for FireDAC.
> 
> How I handle it in IBX.
> 
> {code}
> function TIBXSQLVAR.GetCharsetSize: Integer;
> begin
>    case SQLVar.SQLSubtype and $FF of
> ...
>      3 :
>      begin
>        // System Tables incorrectly state they are in Unicode_Fss character set 
> but they are not
>        if SQLVar.RelName.StartsWith('RDB$') or
>           (SQLVar.SqlLen mod 3 <> 0) then
>          Result := 1
>        else
>          Result := 3;
>      end;
> ...
>    end;
> end;
> {code}
> 
> -- 
> Jeff Overcash (TeamB)
>        (Please do not email me directly unless  asked. Thank You)
> And so I patrol in the valley of the shadow of the tricolor
> I must fear evil. For I am but mortal and mortals can only die.
> Asking questions, pleading answers from the nameless
> faceless watchers that stalk the carpeted  corridors of Whitehall.
>               (Fish)

Hi Jeff, 
Thanx for the reply.

I think your approach will work excellent.

> First in another app (IBEXPert or whatever you use) run
> 
> select * from rdb$fields where rdb$field_name = 'RDB$TRIGGER_NAME'
> 
> Check the RDB$Character_set column.  If that is 3, then FB has the same bug that 
> IB has.  The symptoms seem to indicate it, but that would verify it.
> 

Hi Jeff,
I quickly checked, and yes, it does have a RDB$CHARACTER_SET_ID of 3.
As does a lot of the RDB$ fields.

None of my own fields though.
Question: would it corrupt the data if I change the RDB$CHARACTER_SET_ID to 0-None?
Will it fix my problem?
Will I have any other effect on the data?

Thanks for the help
Willem

> 
> I know of no reason setting that to 0 would negatively impact the DB.  I have 
> never tried it though so try it on a backup and see if you see any issues.  It 
> is the wrong value - the data is ANSI not Unicode_Fss (I had a discussion with 
> Sriram about the InterBase issue last year when fixing IBX on this problem 
> verifying it is wrong). AFAIK it is used strictly for information purposes for 
> the system tables, nothing more.
> 

I have done a quick test and it seems to work.
I will run some more test and report back.

W