pgDAC vs dbexpress for postgreSQL

[lauchuen]

hi,

which one better ?


thanks

[snorkel]

hi,

which one better ?


thanks

The postgresql components from Devart are the best.
For one thing they don't require libpq.dll at all, that means you don't have the dependencies involved with libpq.dll which if you use the official one can be significant.

[Plash]

We recommend using PgDAC. dbExpress technology has many restrictions, flaws and errors. Moreover, PgDAC gives you much more features than dbExpress.

[snorkel]

We recommend using PgDAC. dbExpress technology has many restrictions, flaws and errors. Moreover, PgDAC gives you much more features than dbExpress.

I don't believe codegear even has a dbexpress driver for PostgreSQL.
The only one ever from codegear shipped with Kylix, but they never included it with win32 versions for some reason.

[nenad]

Hallo,

devart has also a postgresql-driver for dbexpress, or ?

I am also thinking about which DB to use -
we are porting from the DBISAM-Db from elevatesoft.

I think Postgresql would be probably the best DB for our needs
(300T Rec per Year, high reliabilty needed)
the questions is which product would be best -
pgdac , the devart dbexpress driver or
maybe even unidac so that we can switch DB's if pg is maybe not good enough ...

"dbExpress technology has many restrictions, flaws and errors."
Can you describe some of them ?

Any other thoughts or reassurances ?

[Plash]

There are some of them:
If you change DataType of a parameter of TSQLStoredProc, you get an error. For example, the parameter has type ftFMTBcd and you assing value using AsInteger or AsFloat property.
Parsing of parameters in SQL is not correct for some cases: it finds parameters inside comments, considers as a parameter expressions like := (important for Oracle) or ::datatype.

[robertoicardi]

We recommend using PgDAC. dbExpress technology has many restrictions, flaws and errors. Moreover, PgDAC gives you much more features than dbExpress.

And you recommen using PgDac over dbexpress even when used
together with datasetprovider/clientdataset stack?

my fear is that when fetching data, while dbexpress is no-cache forward only cursor, pgdac do cache of data by itself, so you end up having double caching (in clientdataset and pgdac) until the fetching operation is over; with little datasets is not a problem, but if you have to fetch a lot of data you have a double usage of memory.... that will of course affect performance also.

[Plash]

TPgQuery has the UniDirectional property. If you set this property to True, query will not hold all data in memory.

[robertoicardi]

TPgQuery has the UniDirectional property. If you set this property to True, query will not hold all data in memory.

For what I've read Unidirectional = True implies FetchAll=False, and this requires an active transaction. How can be achieved to have this transaction active, who and when close this transaction, and this does not then interfere with the fact that datasetprovider when applying updates back open by itself another transaction?
Just to understand....

thanks

[Plash]

In the latest PgDAC version we have added support for automatic starting transaction for FetchAll=False mode. This transaction is started on a separate connection. So you can start and commit transaction on the main connection independently.