Zeoslib Portal

I have spent some time borrowing some code from pgsqlODBC and finally have made PostgreSQL EncodeString() characterset aware. EncodeString() is escaping special bytes which are actually part of multi-byte characters. For example, it is incorrectly escaping the two strings

5cb3 68a6 000a

and

5ca5 e0af 000a

to

5cb3 3331 a634 0a68

and

5ca5 3331 af34 0ae0

This is wrong because backslash '\' is actually part of the original two-byte characters, respectively. They (the backslashes) should not be escaped.

I have not been granted to commit rights. Would someone do the patch asap to avoid the code out of syncronization?

cnliou,

Would it be a big task to get this patch to testing branch? I promised Helmut to keep my hands of Trunk. And we better test this kind of changes in our 'Testing' version to avoid troubles when merging. (Quite a number of people are using this branch now, I think)

Also I've seen you replaced some functions by others. Are yousure this won't break code from users using an older ZEOSLib version? I must admit that I don't understand all that encode/decode stuff and pgsql, so I can't really verify.

Mark

Hi! Mark,

I did try testing branch. Problem is that the code in testing branch appeared to be broken - I got access violation when compiling ZPlainMySqlConstants.pas in BCB6. That's why I turned to trunk branch.

It will not be a trivial task for me to manually do the all same changes to testing branch again as I saw there are many differences between testing and trunk before starting my work on trunk branch. I am not sure I will be able to arrange time for it.

Perhaps it will be fine to patch it directly to testing branch, but it is risky and a question follows: "then what about the trunk branch?"

This also raises a serious question - Is it wise to maintain multiple repositories under limited manpower?

IIRC, GetRawString() is the only function "not?" of mine I have touched this time. I removed it from the code indeed. It was actually myself who added it to sourceforge repository before Zeoslib was moved to this forum. It is the right time now to get rid of it again to make the code more compact and slightly run faster because it is redundant. I don't think the removal of it breaks anything.

More ideas are welcome.

Hi, I'm currently messing with this PlainMysqlDrivers. Works for D7, D5 and D2006.

Can you find out what's going wrong there? I use Delphi 7 with mysql5 to test this stuff, but I admit, I have no clue what can mess up BCB6 (C builder?). Your the first I know using it.

I'll try to get your changes in testing branch, but I don't know when and how. I suppose pgsql hasn't changed a lot between trunk and testing, so It can be relatively easy (but boring) to do the diff merging manually.

Mark

Meanwhile, I applied your changes manually to testingbranch. 1 file was already modified a little, but merging was not problematic. It compiles for me in D5, D6 and D2006. I really hope you find what's wrong for C Builder. If you can't find, please check out the version before I started doing the plain driver stuff. (V54 should be the one you're looking for)
Also,I applied some more commits now. Maybe that fixed something.
So : first update testing branch. See if it's still wrong and eventually try to find out what's wrong.
If you fail to find out revert to version 54 and try again to see whether it's in my changes or not. Maybe C-builder does not work very well with these 'reusable includes' I invented.

Mark

Hi! Mark,

Thank you for the efforts!

I am doing the following tests with C++Builder6 on Testing branch.

BCB6 still raises access violation at line number 426 when compiling ZPlainMysqlConstants.pas as of revision 60.

BCB6 perfectly compiles revision 54 all .bpk packages except for the two errors:

[Pascal Error] ZGenericSqlAnalyser.pas(38): Unit identifier 'ZTokenizer' does not match file name
[Pascal Fatal Error] ZGenericSqlAnalyser.pas(42): File not found: 'ZCore.inc'

The compiler completes its job compiling Zdbc.bpk as of revision 60. I will verify your patch (for my updates) to make sure its completeness after the AV from ZPlain.dpk has been fixed.