Recent

Author Topic: ZEOS dilemma  (Read 17967 times)

TurboRascal

  • Hero Member
  • *****
  • Posts: 672
  • "Good sysadmin. Bad programmer."™
ZEOS dilemma
« on: April 09, 2011, 05:10:29 pm »
I'm working on a new application and I was considering to use ZEOSDBO for several reasons: It works the same for several different RDBMS's which eases switching the backend if needed, it presents a BDE-like approach with ZTable easing simple table access when no special SQL queries are needed, seems to have some more features than SQLDB components in Lazarus, and finally it works the same with Delphi if a colleague wishes to port to it.

Unfortunately, the versions offered last (6.6.6-Stable (don' quite like the ver. number too  ;D) and 7.0-alpha (which is, well, alpha) are dated December 2009! I'm not quite sure what is happenning with ZEOS, will it be maintained and acceptably supported in the future? I would not like to create a new project around something in risk of getting abandoned...

Moreover, I've encountered an instability (ok, crashing to be more specific) when I last time tried using ZQuery with Postgres. I haven't looked much into that problem, but it worked fine when I used PQConnection and SQLQuery combination of Lazarus' SQLDB components. If it's a ZEOS bug, then I'm not sure if it will be fixed soon considering the above mentioned delays...

Instead of ZEOS I could use Lazarus components, where I could still switch backend databases changing the Datasource, SQLQuery and SQLTransaction interconnections with Connector components, but I'm not sure if I'll be missing a feature or a driver from ZEOS; also that way I'd make it harder for someone to reuse the code in Delphi...

I'd appreciate some advice and opinions about the matter... Thanks in advance ;)
Regards, ArNy the Turbo Rascal
-
"The secret is to give them what they need, not what they want." - Scotty, STTNG:Relics

Zoran

  • Hero Member
  • *****
  • Posts: 1592
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: ZEOS dilemma
« Reply #1 on: April 09, 2011, 09:11:46 pm »
First, I must tell that I have never used PostgreSQL, so I can't tell anything specific to that dbms.

Generaly, I have always preferred Zeos to SQLdb. To be honest it is not that have ever been sure that it is really better, but to me it is easier to set up and control.

In SQLdb there is a TSQLTransaction component, but I have found almost no documentation about this component. Okay, I must say that the most important is that this component does have commit and rollback methods and they work as expected. Nothing else is clear about this component. I haven't managed to understand how to use TSQLTransaction.Action property. I tried to set it to diferent values and I could not get it to work as expected, actually it seems that it always behaves the same — the transaction is open until explicitely commited or rolled back and if just closed then it automatically rolls back.

Further, I haven't found a way to control transaction isolation level, it seems that SQLdb lacks the way to set TIL. In Zeos you can do it (using ZConnection.TransactionIsolationLevel property).

In SQLdb there is SQLConnector component, but not a single word explaining its usage can be found! See this unanswered question — it seems that no one knows about it.

SQLdb's documentation is very, very poor. Too poor. :(

Now, about Zeos.
Well, sadly, Zeos development seems to be lately very slow, almost dead. Mark Daems seems to be the only person who tries to keep it alive as much as he can, but one volonteer can't do much, I'd say.

Anyway, my experience with Zeos is that it works well with Lazarus. If you want version 7, do not use the alpha release, but use trunk version from svn, a lot of bugs have been fixed since the "alpha" release.
Even for version 6, it might be better to use "6.6 patches" branch from svn, then "stable" 6.6.6.
« Last Edit: April 09, 2011, 09:15:37 pm by Zoran »

bobo

  • Full Member
  • ***
  • Posts: 171
Re: ZEOS dilemma
« Reply #2 on: April 09, 2011, 09:29:20 pm »
I agree with Zoran.
Though ZEOS development significantly slowed down in the past 2 years, it is still the best and easiest way with FPC/Lazarus.

I am sure the built in SQLDB components could use some tests and feedback to the Lazarus developers, mind you. I am positive they would fix any problems with it if someone just reported them. Unfortunately, lately I did not have time to do any free testing work, especially with ZEOS working so well, the need never arise to replace it with anything else.

I am still using the stable 6.6.6 version (some minor changes were needed with FPC 2.5.1 for it to compile, but nothing major), but I will give a try to the SVN trunk version now.


JD

  • Hero Member
  • *****
  • Posts: 1796
Re: ZEOS dilemma
« Reply #3 on: April 09, 2011, 10:32:12 pm »
If you want version 7, do not use the alpha release, but use trunk version from svn, a lot of bugs have been fixed since the "alpha" release.
Even for version 6, it might be better to use "6.6 patches" branch from svn, then "stable" 6.6.6.

Where can I get the svn versions? svn://zeos.firmos.at/zeos/trunk does not seem to be working.
Windows (10, 7) - Lazarus 2.1/FPC 3.2, Delphi

Indy 10.6 series; mORMot; Zeos 7.3; SQLite, Firebird, PostgreSQL & MariaDB; VirtualTreeView 5.5.3 R1

Zoran

  • Hero Member
  • *****
  • Posts: 1592
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: ZEOS dilemma
« Reply #4 on: April 09, 2011, 10:48:16 pm »

Where can I get the svn versions? svn://zeos.firmos.at/zeos/trunk does not seem to be working.

Strange, I have just tried and it works — "svn://zeos.firmos.at/zeos/trunk".

JD

  • Hero Member
  • *****
  • Posts: 1796
Re: ZEOS dilemma
« Reply #5 on: April 09, 2011, 11:08:10 pm »
@Zoran
What tool are you using? I use RapidSVN & it keeps telling me it can't connect to "zeos.firmos.at". Funny enough, I can go to the website with my browser without problems.
Windows (10, 7) - Lazarus 2.1/FPC 3.2, Delphi

Indy 10.6 series; mORMot; Zeos 7.3; SQLite, Firebird, PostgreSQL & MariaDB; VirtualTreeView 5.5.3 R1

Zoran

  • Hero Member
  • *****
  • Posts: 1592
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: ZEOS dilemma
« Reply #6 on: April 10, 2011, 06:19:14 am »
@Zoran
What tool are you using? I use RapidSVN & it keeps telling me it can't connect to "zeos.firmos.at". Funny enough, I can go to the website with my browser without problems.

Works here with TortoiseSVN in Windows and command line svn in Ubuntu.

fabienwang

  • Sr. Member
  • ****
  • Posts: 449
  • Lazarus is the best
    • My blog
Re: ZEOS dilemma
« Reply #7 on: April 10, 2011, 10:37:08 am »
@Zoran
What tool are you using? I use RapidSVN & it keeps telling me it can't connect to "zeos.firmos.at". Funny enough, I can go to the website with my browser without problems.

JD, i was using RapidSVN but experience a lot of bugs too, so i'm temporary using eSvn until i code my own SVN Client :D
I'm using Arch Linux.
Known for: CPickSniff, OpenGrabby
Contributed to: LazPaint

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8780
  • FPC developer.
Re: ZEOS dilemma
« Reply #8 on: April 10, 2011, 12:24:47 pm »
I use zeos(7)-trunk with postgresql8 in for several small database apps (at work, using Delphi XE), and have no significant problems.

The only big gotcha I would want to warn for is that sometimes the designtime components import state silently.

Example:

1. I miswrote a query, and uppercased a letter from the table
2. Everything was read/write, but Zeos declared the table read-only on start.
3. I imported some fields from the table, hid some fields in the dbgrid etc.
4. noticed the wrong capitalization, and corrected it.

However the problem persisted: reason, for importing the fields, the connection/query was used and gotten readonly, and all fields had inherited the "read-only" property.

Took me a day to figure this out, I was already stepping through the zeos source :-)

TurboRascal

  • Hero Member
  • *****
  • Posts: 672
  • "Good sysadmin. Bad programmer."™
Re: ZEOS dilemma
« Reply #9 on: April 12, 2011, 02:31:38 am »
So it seems zeos is still the best bet...

According to your recommendations, I got the code from trunk (used RapidSVN, checked out with no problems), installed that and started working with it. Hopefully it will serve me as good as you reported :)

Thank you for your answers ;)
Regards, ArNy the Turbo Rascal
-
"The secret is to give them what they need, not what they want." - Scotty, STTNG:Relics

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8780
  • FPC developer.
Re: ZEOS dilemma
« Reply #10 on: April 12, 2011, 10:29:11 am »
So it seems zeos is still the best bet...

According to your recommendations, I got the code from trunk (used RapidSVN, checked out with no problems), installed that and started working with it. Hopefully it will serve me as good as you reported :)

Thank you for your answers ;)

Another tip for beginners: make sure you set the codepage of the database in the connection as early as possible. This avoids unicode problems later.

JD

  • Hero Member
  • *****
  • Posts: 1796
Re: ZEOS dilemma
« Reply #11 on: April 12, 2011, 10:55:50 am »
Another tip for beginners: make sure you set the codepage of the database in the connection as early as possible. This avoids unicode problems later.

I found that out the hard way. It was very painful!  :(
Windows (10, 7) - Lazarus 2.1/FPC 3.2, Delphi

Indy 10.6 series; mORMot; Zeos 7.3; SQLite, Firebird, PostgreSQL & MariaDB; VirtualTreeView 5.5.3 R1

Zoran

  • Hero Member
  • *****
  • Posts: 1592
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: ZEOS dilemma
« Reply #12 on: April 12, 2011, 11:48:43 am »

Another tip for beginners: make sure you set the codepage of the database in the connection as early as possible. This avoids unicode problems later.

I put "codepage=UTF8" in ZConnection.Properties. This informs the server that client encoding is utf8 (which is always so in Lazarus). Then encoding should work correctly.
However, in the 6.6.6 "stable" version it does not work well with Oracle, but in Zeos 7 (trunk version) it is repaired. With Firebird it works well, no matter which of these versions is used. I don't know about Postgres, try it.

This can be confusing but it is not about the database encoding, but the client encoding. So, no matter which your database encoding is, you should put the "codepage=UTF8" line in your ZConnection.Properties property, as it tells the server which is encoding of the client.

TurboRascal

  • Hero Member
  • *****
  • Posts: 672
  • "Good sysadmin. Bad programmer."™
Re: ZEOS dilemma
« Reply #13 on: April 12, 2011, 12:19:18 pm »
Thanks for the caracter encoding tips! I believe there shouldn't be any problems with Postgres, especially since I'm setting its encoding to UTF8 too...
Regards, ArNy the Turbo Rascal
-
"The secret is to give them what they need, not what they want." - Scotty, STTNG:Relics

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8780
  • FPC developer.
Re: ZEOS dilemma
« Reply #14 on: April 12, 2011, 12:22:33 pm »
Thanks for the caracter encoding tips! I believe there shouldn't be any problems with Postgres, especially since I'm setting its encoding to UTF8 too...

My case was about postgress, and you DO need to set it there (codepage=utf-8 or utf8 in the connection properties). Keep in mind you have to set it on both ends, client and server.

 

TinyPortal © 2005-2018