Read-only?

[Dali]

Hello!

It's been a while since my last visit here, sorry about that.

Now, back to business, I have an application which interacts with a very old Interbase 6.0 database. Upgrading that database to any other version of Interbase or Firebird is not an option. If I recall right, Zeos 7 won't support Interbase 6, so I'm stuck with v6.6.

My app was working fine until I upgraded Zeos 6.6-patches from SVN. Now, every time I try to do a POST operation an exception is thrown, saying that "can't update a readonly field" (I insist, with the previous, really old SVN version I had before everything was working fine).

I traced the exception back to ZAbstractRODataSet. It seems that the query, which is NOT ReadOnly and involves only ONE table, is returning ReadOnly fields. So, I tried to workaround that using this two lines of code right after the dataset is made active:

Code: Select all

    for i:=0 to dsComb.dataSet.fieldCount-1 do
        dsComb.dataSet.fields[i].readOnly := false;

... And now the exception won't be thrown BUT another one shows up, saying that "can't update this query type". This exception is thrown from TZGenericCachedResolver.DefineTableName which is placed in ZDBCGenericResolver unit.

I tried using both upper and lower cased field and table names (I had this problem before with a PostgreSQL database and I fixed it using this approach), but I still get the same error. Not only this, but NO OTHER post operation will work either. That means I can't make any changes to the app because the new version I need to release does absolutely nothing but displaying an error message.

So, please, any help would be very appreciated.

[Dali]

More info on this issue: I'm using latest Lazarus 1.3 and FPC 2.6.4.

My current revision of 6.6-patches is 3472. The previous one was revision 903 (as I said, very old, and hosted by an older repository).

[Dali]

OK, so I tried with latest stable version, 7.1.4, from svn, revision 3477.

Everything compiled and I saw there's still support for Interbase 6, but now it's even worse, I can't even connect.

The exception I get is caused by some metadata SELECT which uses the function TRIM, which is unknown in Interbase.

I tracked down the error and located it at ZDBCInterbase6Metadata Unit:

Code: Select all

function TZInterbase6DatabaseMetadata.ConstructNameCondition(Pattern: string;
  Column: string): string;
begin
  Result := Inherited ConstructnameCondition(Pattern,'trim('+Column+')');
end;

I changed it in this way:

Code: Select all

function TZInterbase6DatabaseMetadata.ConstructNameCondition(Pattern: string;
  Column: string): string;
begin
//  Result := Inherited ConstructnameCondition(Pattern,'trim('+Column+')');
  Result := Inherited ConstructnameCondition(Pattern,Column);
end;

... And now it's working like a charm without changing anything else in my own code!

[Sergiomaster]

Hello,
an other was to use UDF rtrim and lTrim (as far i remember existing in Interbase 5.5)
shall something like

Code: Select all

Result := Inherited ConstructnameCondition(Pattern,'ltrim(rtrim('+Column+'))');

works ?

[EgonHugeist]

I know about this issue. See: http://sourceforge.net/p/zeoslib/tickets/105/

so RTRIM doesn't handle the issues as i want to have it.

Note: We did introduce trim because of metadata determinations for tables like 'Foo', 'Foo1', 'Foo2'. If we want to have infos about foo and using the old 'like' syntax we badly get results for all these tables.

Help would be welcome. Any ideas how we can find a common way? Note i introduced version checks for FB vs. Interbase and it's version numbers on 7.2. But the issue remains for the old servers....

Wondering Dali's patch works since the field is a fixed character field on my FB. Is it a VARCHAR field in interbase?

[Dali]

Thank you guys for your replies.

I have not your expertise and I barely can follow your explanations to understand what's happening here, but I did check the RDB$FIELD_NAME type into RDB$FIELDS system table as advised and, yes, it is actually a fixed lenght string, char(31) to be accurate.

I don't know why that little change I made works, but it does the trick for me. Excuse my ignorance but, does it really need to be trimmed at all in the first place? Maybe the comparison against a VARCHAR string takes care of this already and works without it because internally the fixed length string 'XXX ' will match with the string 'XXX' because it will skip the spaces from the first one, knowing its size is fixed and it's most likely to have some trailing spaces.

I haven't looked very deeply into this since, as I said, I lack of the expertise, so, then again, sorry if I'm not making any sense with this theory.

[EgonHugeist]

Dali could you please check: http://zeoslib.sourceforge.net/viewtopi ... 895#p36895

Please read all my detail links and join the discussion.