Zeoslib Portal

Newer versions of PostgreSQL appears to handle escape syntax differently from older ones. Version 9.2 takes literals like these two SQL text: INSERT INTO t1 VALUES (E'This is Jim\'s home.') INSERT INTO t1 VALUES (E'This is Jim\047s home.') Take special note on the prefixing character "E"! ...

Using the 3 step cast as in the example doesn't work either? - Create IZPostgresSQLConnection object variable - Assign this variable a value by casting - Use the var->SetCodePage() function. No, this can't compile: IZPostgreSQLConnection *c=static_cast<IZPostgreSQLConnection *>(ZConnection->DbcConn...

I think you better read this article : http://zeos.firmos.at/kb.php?mode=article&k=14 It's the SQLite specific implementation of encryption functionionality. It shows how you can use code to call db-specific dbc layer functions. What do you think? Can you manage this change for the postgres dri...

It will be fine for myself to make SetCodePage() available only to PostgreSQL. However, I don't know how to directly call zdbc procedures from my application. If you can show me how, I can try exporting SetCodePage() to zdbc instead of TZConnection. I have read http://zeos.firmos.at/kb.php?mode=art...

I have just quickly reviewed mysql, sqlite, and interbase6. It appears to me that none of them reacts to the change of "codepage=..." after connection, and sqlite even completely ignores this parameter. It will be fine for myself to make SetCodePage() available only to PostgreSQL. However,...

I have fixed the issue and uploaded the patch to:

http://zeos.firmos.at/viewtopic.php?p=13813#13813

Hopefully the patch will be accepted and manually patched by some good soul

This is the patch to fix the flaw as mentioned by myself at http://zeos.firmos.at/viewtopic.php?p=13794#13794 I have just fixed the flaw and the result looks fine. Summary of the rework: - Ignore entry "codepage=..." in TZConnection.Properties. That is said, setting this entry does not cha...

Hi! Client encoding is specified in TZConnection.properties such as "codepage=big5". It is then parsed and converted by Create(), and saved as FClientCodePage in ZDbcPostgreSql.pas. Such design works but it has the following flaws: (1) After connected to PostgreSQL, users can send "SE...

Confirmed: under Sqlite3 the above code works perfectly giving expected results. Well, so it looks like it's time to bug hunt for me! 8) The following message explains the reason: https://support.zabbix.com/browse/ZBX-4145 Quick and dirty temporary work around is explicitly turning off the followin...

At the VCL component level (e.g. TDataSet or TQuery Zeos versions), the type for strings will be the plain Delphi string type. For instance, SQL.Text will expect string type, i.e. UCS2 since Delphi 2009. The UTF-8 encoding will be used only at lower level, i.e. at ZDBC level. All the conversions wi...

- you've to call our custom UTF8ToString() or StringToUTF8() to convert to/from VCL string type - this will work for Delphi 6 up to XE and is very fast (avoid using Windows API most of the time); Please help me get your point. Zeoslib would not be quite usable if you mean the higher level applicati...

Therefore, if your DB uses UTF8 encoding and the client uses UTF16, then you should put "codepage=UTF16" (or maybe "codepage=UCS2"?). Then Zeos will tell the server to convert data to and from UTF16 (UCS2) encoding. The problem happens when the DBMS like PostgreSQL does not supp...

I beleive that most of those DBs will convert all data to client encoding before sending it to client (and in the oposite direction convet it from client encoding before storing it). Could this make your job simpler? Then, it does not matter if diferent tables and diferent columns in the base store...

I am getting the feeling that the UNICODE issues are cross databases. What we actually need is perhaps a generic UNICODE implementation for all drivers. File "multibyte.c" in psqlODBC is an invaluable resource for us in terms of its quality. Please also refer to bug ID# 228: http://zeosbug...

I would suggest start with "unsecured" settings in pg_hba.conf:

local all all trust
host all all 127.0.0.1/32 trust

After the connection from ZEOSLIB succeeds, then set pg_hba.conf more secured.

(Remember to restart postgresql every time after changing pg_hba.conf).

Regards,
CN