Delphi connection ?

Nico Callewaert wrote:

Hi List,

I tried already in the ODBC list, but without success...

I have to develop a client/server application, heavily transaction
oriented, that will serve around 100 users and database traffic will be
intense (lot's of reads, updates, inserts....).
Development environment is Delphi 2007. I know there are a few
commercial components available, but I was wondering if ODBC could do
the job ?
So, my question is, if ODBC is intended to be used for that ? Many
simultanous connections, lots of inserts, updates ?
The thing you always hear about ODBC is, that it is very slow ?

Many thanks in advance,
Best regards,

Nico Callewaert

I don't know about odbc, never used it to hit PG. I use Delphi and
wrote a simple object on top of the libpq api. The api is simple to
use. If odbc doesn't work out for you I'd recommend using libpq direct.

-Andy

Nico Callewaert wrote:

Hi List,

I tried already in the ODBC list, but without success...

I have to develop a client/server application, heavily transaction
oriented, that will serve around 100 users and database traffic will
be intense (lot's of reads, updates, inserts....).
Development environment is Delphi 2007. I know there are a few
commercial components available, but I was wondering if ODBC could do
the job ?
So, my question is, if ODBC is intended to be used for that ? Many
simultanous connections, lots of inserts, updates ?
The thing you always hear about ODBC is, that it is very slow ?

ADO is significantly faster than ODBC, so the preferred stack would be
delphi -> ado -> postgres ole db -> libpq ->postgres

I believe there exists a delphi->ado wrapper (at least my brief googling
popped one up)

On Fri, Sep 25, 2009 at 5:16 AM, Nico Callewaert
<callewaert.nico@telenet.be> wrote:

Hi List,

I tried already in the ODBC list, but without success...

I have to develop a client/server application, heavily transaction
oriented, that will serve around 100 users and database traffic will be
intense (lot's of reads, updates, inserts....).
Development environment is Delphi 2007.  I know there are a few commercial
components available, but I was wondering if ODBC could do the job ?
So, my question is, if ODBC is intended to be used for that ?  Many
simultanous connections, lots of inserts, updates ?
The thing you always hear about ODBC is, that it is very slow ?

It's been a few years, but historically the best delphi components for
database access has been ZeosLib...native connections to most popular
databases...

merlin

Thank you to all for the interesting replies !

Best regards,
N.

On Fri, Sep 25, 2009 at 9:39 AM, John R Pierce <pierce@hogranch.com> wrote:

ADO is significantly faster than ODBC, so the preferred stack would be
 delphi -> ado -> postgres ole db -> libpq ->postgres

Is the oledb driver stable? Its never development status has never
changed from Beta over the last few years.
http://pgfoundry.org/projects/oledb/

--
Regards,
Richard Broersma Jr.

Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

Andy Colson wrote:

Nico Callewaert wrote:

Hi List,

I tried already in the ODBC list, but without success...

I have to develop a client/server application, heavily transaction
oriented, that will serve around 100 users and database traffic will
be intense (lot's of reads, updates, inserts....).
Development environment is Delphi 2007. I know there are a few
commercial components available, but I was wondering if ODBC could do
the job ? So, my question is, if ODBC is intended to be used for that
? Many simultanous connections, lots of inserts, updates ?
The thing you always hear about ODBC is, that it is very slow ?

Many thanks in advance,
Best regards,

Nico Callewaert

I don't know about odbc, never used it to hit PG. I use Delphi and
wrote a simple object on top of the libpq api. The api is simple to
use. If odbc doesn't work out for you I'd recommend using libpq direct.

I have using an older Delphi (v3), ODBC itself I believe was fine but
the BDE layer introduced problems- apps needed to be rebooted evey month
or so.

Note that ODBC doesn't easily support any non-standard facilities, e.g.
listen/notify.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

On Tue, Sep 29, 2009 at 8:27 AM, Mark Morgan Lloyd
<markMLl.pgsql-general@telemetry.co.uk> wrote:

Andy Colson wrote:

Nico Callewaert wrote:

Hi List,
 I tried already in the ODBC list, but without success...
 I have to develop a client/server application, heavily transaction
oriented, that will serve around 100 users and database traffic will be
intense (lot's of reads, updates, inserts....).
Development environment is Delphi 2007.  I know there are a few
commercial components available, but I was wondering if ODBC could do the
job ? So, my question is, if ODBC is intended to be used for that ?  Many
simultanous connections, lots of inserts, updates ?
The thing you always hear about ODBC is, that it is very slow ?
 Many thanks in advance,
Best regards,
 Nico Callewaert

I don't know about odbc, never used it to hit PG.  I use Delphi and wrote
a simple object on top of the libpq api.  The api is simple to use.  If odbc
doesn't work out for you I'd recommend using libpq direct.

I have using an older Delphi (v3), ODBC itself I believe was fine but the
BDE layer introduced problems- apps needed to be rebooted evey month or so.

Note that ODBC doesn't easily support any non-standard facilities, e.g.
listen/notify.

The BDE was terrible, as were the native drives that Borland provided
with Delphi (Paradox, etc). 3rd party drives (Zeos) eventually
arrived to fix the problem but by that point Delphi had lost the war
with Visual Basic. That's really tragic, because even early versions
of Delphi/c++ builder are STILL the best win32 development tools out
there in many ways...especially designing interfaces.

merlin

On 29/09/2009 13:39, Merlin Moncure wrote:

The BDE was terrible, as were the native drives that Borland provided
with Delphi (Paradox, etc). 3rd party drives (Zeos) eventually
arrived to fix the problem but by that point Delphi had lost the war
with Visual Basic. That's really tragic, because even early versions
of Delphi/c++ builder are STILL the best win32 development tools out
there in many ways...especially designing interfaces.

I fully agree.... I still use Delphi 6 a lot, and there's an ease of use
about it that leaves other IDEs I've used in the shade. It's just a pity
that it's so expensive....

Ray.

------------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@iol.ie
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
------------------------------------------------------------------

Raymond O'Donnell wrote:

I fully agree.... I still use Delphi 6 a lot, and there's an ease of use
about it that leaves other IDEs I've used in the shade. It's just a pity
that it's so expensive....

Ray.

------------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@iol.ie
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
------------------------------------------------------------------

I trust you've investigated Lazarus?

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

John R Pierce wrote:

Nico Callewaert wrote:

The thing you always hear about ODBC is, that it is very slow ?

ADO is significantly faster than ODBC, so the preferred stack would be
delphi -> ado -> postgres ole db -> libpq ->postgres

I believe there exists a delphi->ado wrapper (at least my brief googling
popped one up)

Granted that this is a general query issue rather than one specific to
Delphi/ODBC etc., but the major speed problem that I see is where I have
a clause approximately like

WHERE now() - datetime <= '24 hours'

repeated several times in a query (e.g. in subselects or views). The
easiest solution is to replace this with a function returning an
timestamp which is evaluated once during query execution.

The moral of the story is that even if your queries are wrapped in a
fancy program generated by something like Delphi, always leave yourself
a way that you can extract a representative query after any
parameterisation and do an EXPLAIN to look for inefficiencies.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]