Zeoslib Portal

Hey Zeos-Users

I did some Patches:

1. fixed the missing FireBird-MetaData-Type UncachedGetCrossReference and enabled it in the testsuits.

2. SQLite-Unicode-Support for Delphi12_UP

3.added Metadata types for MySQL, SQLite, PostgresSQL, Firebird/Interbase:
mdCollationAndCharSet ->
GetCollationAndCharSet(const Catalog, SchemaPattern,
TableNamePattern, ColumnNamePattern: string): IZResultSet;
mdCharacterSets ->
function UncachedGetCharacterSets: IZResultSet;

4. Added a property-Editor to TZAbstractConnection: ClientCodePage which is auto arrange the Codepage=... in the TZAbstractConnection.Properties.
aviable for MySQL, SQLite, PostgresSQL, Firebird/Interbase now.


5. Did some Delphi12_UP Upgrades and boiled down some Compiler-Warnings.

Best regards,

EgonHugeist

Hi EgonHugeist

Are you doing this patches for Delphi 2009+?

Hey papelhigienico,

absolutly Compiler-independent... I've an aditional Patch ready. But mark must give his ok for it. This 968 Patch is only a little Preview for what is comming if Mark giv's his sign to upload it. It autoarranges all Compiler-specific String/Variant-Types-handlings. Then there are no more Compiler-spezcific neccassary then in the Core-package. Unicode should be possible for all Pascal-Compilers and free Databases.

But like i sayd ca. 5000 changed Code-lines are too much to do this without mark's ok.

Best regards Michael.

btw. what about my sended Component and the Postgres-Fixes we wrote before?

EgonHugeist, I'm working a lot on another parts of PascalSCADA (I use it on my job) so, I stopped the work on database layer, but I'll return soon. I'm a little off from Zeos forum too

EgonHugeist wrote:Hey papelhigienico,

absolutly Compiler-independent... I've an aditional Patch ready. But mark must give his ok for it. This 968 Patch is only a little Preview for what is comming if Mark giv's his sign to upload it. It autoarranges all Compiler-specific String/Variant-Types-handlings. Then there are no more Compiler-spezcific neccassary then in the Core-package. Unicode should be possible for all Pascal-Compilers and free Databases.

I'm also working on a big patch, that structures all ifdefs to remove versions as much as possible from the sources, to upgrade the current (2.2.0 or so) FPC support to 2.6.0 and prepare for more D2009 like changes to come (like that all new versions of FPC will use trecordbuffer)

Some parts can be broken into multiple patches though (like changing most pbyte casts to TRecordbuffer)

A sample:

http://www.stack.nl/~marcov/zeos.patch


Will any of the developers attend FOSDEM next weekend?

marcov,

Is this ready and tested?

The coming FPC 2.8 handles the String as UnicodeString like Delphi_12UP. I see you working on the TRecordBuffers.. so we can combinate our patches if you want.

btw. shouldn't it be better to make a Type declaration at the begin of the unit and spezify a PZRecodBuffer = {$IFDEF WITH_TRECORDBUFFER} TRecordBuffer {$ELSE} PChar {$ENDIF}; and arrange the functions/procedures to this PZRecodBuffer?

Regards

EgonHugeist

EgonHugeist wrote:marcov,

Is this ready and tested?

I think it is most important to finalize the changes to the .inc files, and stop using versionnumbers directly in the main sources. The changes should be fully backwards compatible. (only a lot of extra defines are generated)

This way, a certain workaround is much easier expandable to another version or compiler.

The coming FPC 2.8 handles the String as UnicodeString like Delphi_12UP.

No, that is not decided yet.

Yes, it will have unicodestring and ansistring (encoding) like D2009+, but what will be the default string type (and if it varies per platform, with string=ansistring(CP_UTF8) a serious possibility on non-unix) is yet to be decided. And since all system classes (tstringlist etc) use the default stringtype, trying to use a different type will leave one in conversion hell, with conversions needed in many places.

A dual possibility (having two different modes with two different RTLs per target, one with the default stringtype 1-byte (for unix compat and "old" delphi), one with defaultstring=2-byte) was also suggested, and has my preferences.

I see you working on the TRecordBuffers.. so we can combinate our patches if you want.

I'm not sure if this is the best way. It might be better to make everything TRecordBuffer and define TRecordBuffer=pchar on older Delphi's and FPC's.

Note that FPC 2.6.2 (after summer probably) will be TRecordBuffer but with TRecordbuffer=pchar. FPC 2.8 will change that to pbyte, but to avoid long dual maintenance we will make that change only just before 2.8

marcov,

think it is most important to finalize the changes to the .inc files, and stop using versionnumbers directly in the main sources. The changes should be fully backwards compatible. (only a lot of extra defines are generated)

This way, a certain workaround is much easier expandable to another version or compiler.

I agree! Absolutly! Actually there is no realy way to workaround but minimizing all directives is a gooooood solution.

No, that is not decided yet.

Hmm, i read it in a german lazarus forum. So this could be wrong. Anyhow we need more transparency in the source codes insted of compiler-directives...

if your're ready please let me know.

mDeams created a new testing-branch for my way's.

EgonHugeist wrote: absolutly Compiler-independent... I've an aditional Patch ready. But mark must give his ok for it. This 968 Patch is only a little Preview for what is comming if Mark giv's his sign to upload it. It autoarranges all Compiler-specific String/Variant-Types-handlings. Then there are no more Compiler-spezcific neccassary then in the Core-package. Unicode should be possible for all Pascal-Compilers and free Databases.

I did a small fix to compile Zeos on FPC and Delphi 2009-

Thanks for your work. Can your please checkup the functionlaity of the testing-egonhugeist folder? And can you do some bugreports please?

Just an update on the 'marcov patch'. Today I checked the status of this patch an I agree we should implement it, even if it's not completely done yet.
I prefer Marco commits it himself so we can help/merge/test/... where necessary.

Mark

Done

Thanks Marco!

I hope we didn't upset you by doing some extra cleanup already. I only did the easy part (removing unused defines).
Don't hesitate when you see room for more improvements. The Delphi12_up stuff is still a huge job.

Mark