Обсуждение: Delphi connection ?
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
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]