pgDAC vs dbexpress for postgreSQL
pgDAC vs dbexpress for postgreSQL
hi,
which one better ?
thanks
which one better ?
thanks
Re: pgDAC vs dbexpress for postgreSQL
The postgresql components from Devart are the best.lauchuen wrote:hi,
which one better ?
thanks
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.
I don't believe codegear even has a dbexpress driver for PostgreSQL.Plash wrote:We recommend using PgDAC. dbExpress technology has many restrictions, flaws and errors. Moreover, PgDAC gives you much more features than dbExpress.
The only one ever from codegear shipped with Kylix, but they never included it with win32 versions for some reason.
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 ?
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 ?
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.
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.
-
- Posts: 27
- Joined: Wed 28 Jan 2009 11:29
And you recommen using PgDac over dbexpress even when usedPlash wrote:We recommend using PgDAC. dbExpress technology has many restrictions, flaws and errors. Moreover, PgDAC gives you much more features than dbExpress.
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.
-
- Posts: 27
- Joined: Wed 28 Jan 2009 11:29
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?Plash wrote:TPgQuery has the UniDirectional property. If you set this property to True, query will not hold all data in memory.
Just to understand....
thanks