Hello:

I'm using Lazarus 1.6 svn: 5163, on Windows XP

I'm porting a small utility that connects to a Firebird database. The utility uses Zeoslib and as Zeoslib has been ported to Lazarus it was almost straight, but I have come across with a problem.

In some place it calls Field.size, but returns the double of the real size of the field. I read that it could be related to character encoding. It assumes that for utf-8 or utf-16 and it could need twice bytes to store the same characters.

The question is that the database has as default character set win1252, all the fields are win1252. The Zeos connection component has a property "ClientCodePage" that allows values UTF8 and UNICODE_FSS, There is another property "AutoencodeString" boolean. No combination works, I always get double size.

I can't change the Database codepage, and it must run on a W-XP, so as a quick workaround I just made the dirty hack of dividing by 2 the result of field.size.

But now, I've read a thread in freepascal about encoding and I wonder wether the problem is more related to freepascal 3.0 than to zeoslib. Is there some compiler directive about string encoding I should be aware of?

Santiago A. wrote

But now, I've read a thread in freepascal about encoding and I wonder wether the problem is more related to freepascal 3.0 than to zeoslib. Is there some compiler directive about string encoding I should be aware of?

I've had this problem for years with ZeosLib even using FPC 2.6.4 and FPC 2.6.2. So it's not related to FPC 3.x the tiOPF unit tests results: [Zeos_FB] -> TTestTIQueryZeos -> FieldSize

"Group_Str_Field" Expected: "10" But was: "40"

http://geldenhuys.co.uk/tiopf/unittests/freebsd64.html

Regards,
Graeme

El 10/05/2016 a las 12:35, Graeme Geldenhuys escribi?:

Any workaround in addition to hardcoded division?

Wow. There is no persistent layer that uses a DB that works properly. Is that a FPC problem?

Santiago A. wrote

El 10/05/2016 a las 12:35, Graeme Geldenhuys escribi?: It used to work in delphi. What's wrong in FPC? Any workaround in addition to hardcoded division?

No, I don't have a solution.

Wow. There is no persistent layer that uses a DB that works properly. Is that a FPC problem?

FPC does have more problems than Delphi - but most of the times it is down to how the test suit was configured. I've been using FPC + SqlDB + Interbase since 2006 - no issues here.

SqlDB_SQLite3 only has one very minor issue with milliseconds rounding error.

Zeos_FB only has the FieldSize anomaly. Good thing is, Zeos returns a larger size than what the application expects, so shouldn't have an affect on your application. The other issue shown is actually a "dirty" database issue. I need to improve the test suite to start each test run with clean empty databases per persistence layer.

I'll not touch MySQL with a 10-foot pole, so I'll leave that to contributors to resolve.

The test failures are all minor and very few considering the amount of tests being run against each persistence layer. It looks worse than it really is.

Regards,
Graeme